1. 没用过也不打算用
2. 安全共享任意平台公共账号。举个例子，企业内部经常会出现多个人登录同一账号，互相顶号，而多数能解决此类问题的方案都不完美，用浏览器本身去解决是最好的。

第一个随时有可能再被裁，你应该先找一个看上去稳定的，offer2 如果拿齐 2 个月年终和 offer1 一样，没得选我会优先考虑这个。现在满大街都是 web3 初创，没一个靠谱的，95%都是骗投资的玩意，靠谱的轮不上你。

早结束哩，单纯冲着无限 tab 其实也不亏。无限 auto 也就那样，有限速你根本用不了多少，正常用的话 20 刀是够用的，重度考虑 60 刀，天天 vibe coding 的上 200 刀。

@javalaw2010 #8 这里不能用 datetime ，跨夏令时那天会少一小时，只能是两个 timestamp ，相减是正确的。不过 timestamp 的问题是用户去了别的时区记录会不正常，比如临时去日本旅游几天，那么所有不在日本的时间都会往后推一小时，必须要一个单独的 timezone 字段。

@wwk 最大的问题是性能问题，prisma 一些很简单的操作会生成多个 SQL ，例如几年前 prisma 的 update 一直都是生成 select+update+select 至少 3 个语句，某些情况下会增加到 6 个，这问题至今没有完全解决，复杂联表查询就更不用说了。
而相比之下 drizzle 基本都保证只有一次操作，drizzle 出圈除了营销很大原因是因为性能实在太好，相比原生 sql 几乎感受不到额外开销。而 prisma 很容易碰上莫名其妙的慢 SQL ，一通排查发现是 prisma 自己的问题，再找到 issue 发现存在很久没有任何进展，因此只能无奈地回退拼接 SQL ，类似 issue 我看得都麻木了。
再来就是 DX ，drizzle 的 schema 与 typescript 融合得很完美。prisma 的自定义 schema 很垃圾，间接导致 prisma 的 ts 支持并不理想，json 类型至今还是 any ，使用社区插件又引入新的问题。Model 的设计首先是无法继承，被迫多写很多重复性字段定义，其次让连表查询相当困难，嵌套多不说，最恶心的是一些简单的连表+动态查询不得不回退 SQL 拼接。
prisma 主打的就是类型安全，而实际上很难能称之为安全，相反 drizzle 的设计是真的能避开很多低级运行时隐患，缺点是比较复杂的场景要跟 typescript 打架。

drizzle 的 bug 确实不少，但是对我来说暂时都有办法解决，生产环境目前没有遇到过问题。

看样子 OP 不会敲代码，我建议放弃

@gxt92 我的错，OP 是试用期，可以拿 0.5-1 个月的赔偿。

@gxt92 实习期没有赔偿。有些公司的实习期长达 6 个月，最后再辞掉，换下个人进来。

@javalaw2010 #6
"2025-09-19 14:44:00"，有可能一条的时区是 Asia/Shanghai, 另一条的时区是 Asia/Tokoyo ，这是你的业务场景。
驱动要将一个绝对时间转成有时区的相对时间，默认操作是以 ioc 参数进行转换。
而你想的是在这里由业务层进行处理，第一条用 Asia/Shanghai ，第二条用 Asia/Tokoyo ，这样就能解析出正确的本地时间。

但请思考这样一个场景：
上海客户在下午 3 点创建订单，1 分钟后日本客户在下午 4 点 1 分创建订单，又 1 分钟后越南客户在下午 2 点 2 分创建订单。
对服务器来说，如何能形成一个正确的时间线，3 点->4 点 1 分->2 点 2 分？
在你这个场景下，已经无法区分了，因为所有时间被转换成当地时间，每个时区的订单都以自己为基准，失去了与其他区比较的中心坐标，如果要正确处理又得以一个标准(例如 UTC)统一转换，增加了复杂度。
进一步，上海客户飞到了美国，此时你要用哪个时区给他解析呢？
一旦驱动真的把解析时间的权利交给开发者，又要多出无数屎山。

在这里我们要先统一共识，时区是什么？时区解决了什么问题？
时区是绝对时间的相对偏移，与地理位置和政治有关，解决了如何将一个绝对时间在全球不同地方展示为当地时钟时间。
服务器不应当关心时钟时间，或者只应当关心以一个时区作为始终标准的时钟时间，例如 UTC0 ，任何时间都要以此标准进行统一，丢弃原本时区信息。全世界任意一个地方要获得正确的时钟时间，应该依赖客户端，而非服务端，服务端要做的仅仅是统一标准。
而原本时区信息在某些场景下是有意义的，Oracle 、PostgreSQL 等提供了 TIMESTAMP WITH TIME ZONE ，但是 MySQL 没有，只能自己存一个 zone 。

>我认为这个地方更适合交由业务层自行处理啊
因此可以回答这个问题，不同时区有不同的业务逻辑是合理的，但是自行处理时区时间是不合理的。

服务器、数据库、驱动都会有这么一个时区配置，这是为了设定自身的基准，它们可以不一样并且是合理的，但是在分布式满天飞的当下，全部使用 UTC 是最简单最没有心智负担的做法，把各种转换问题全部扔掉。或者直接使用 BIGINT 。

>时区就会非常混乱
时区的混乱是历史遗留问题，也是开发者对历史遗留问题选择了错误的解决办法。
甚至还有各种屎山手动加减时区，也是服了。

结贴，研究下黄钻怎么来。

今天想改名，试了一圈都被占用了，只能随便改个

过了保质期应该也只能降薪了，程序员过了 35 就是相当的难，我的前上司能力非常出色，照样 35 被裁，降薪不少才找到下家。他跟我说，已经做好这是人生中最后一份工作的心理准备了，再被裁就回老家种茶叶。

@meteora0tkvo 没人能忍，2345/360/wps 等软件可以任意修改用户配置，下载其他软件，被称为流氓软件已经二十年，有用吗，唯一的手段只有不使用国产软件。

@alioth0909 #2 我的看法是那篇 reddit 帖子完全正确，标记 AI 与抵制 AI 是完全不同的两件事。
我极度支持 Stack OverFlow 禁止任何 AI 回复，而后面 v2 也采取了相同的做法。所有论坛/交流平台，都应该完全杜绝一切纯 AI 产物，这仅仅是在危害人类文明发展。

注意，这与我身为开发人员支持 vibe coding 是不冲突的。
何为 vibe coding ？
开发人员未经人工检查和验证生成大量代码。
这好吗，好也不好，需要从两个方面去审视，只会选择"好"或"不好"二者其一都是浅薄的。

>似乎我们对于 AI 编程这样的提效工具，有更大的热情
你可以去看看油管，各路外国高手以什么样的热情在研究 vibe coding 。
而这个论坛中，又有多少人拒绝学习 AI 知识， 拒绝定制 rules ，拒绝 MCP 。

> 很多人对“工艺感“和”可维护“有更高的要求，从而对 vibe coding 有一定的偏见
对“工艺感“和”可维护“有坚持的那些人，都在以远超普通程序员的效率使用 AI 编程，从而节省下大量时间用于“工艺感“和”可维护“，这依然是不冲突的。