@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 编程，从而节省下大量时间用于“工艺感“和”可维护“，这依然是不冲突的。

八股就别看了，还考八股的也没必要去。
聚焦在学习本身，代码本身，如果学习得足够深入，就会真正碰上八股文里的问题，通过实践得出来的知识才能真正记住并且能说出自己的理解，而不是照本宣科说一通教科书废话。

如果是应用层的没啥难度，最基础的就是调接口，调整提示词，难一点的要设计工作流，可以用 dify 这种可视化的。
无法接受离职，就谈好了把开发周期拉长，一定要给足学习的时间。
现在阿猫阿狗都知道要做 AI ，但是怎么做，上层不管，只要求底下人凭空变出来，这样公司已经在死亡的路上了。

以偏概全，你用数篇帖子，脑补出整个欧美国家都在抵制 vibe coding ？ v2 抵制 vibe coding 的帖子也不少啊，怎么说。
你要对比中美文化，不能用身边统计学+量子脑补，最起码也要深入调研一下。

@june4 #22 vue 最大的一个问题就是没有需求，创造需求。vue3 进展缓慢，这些不去解决，反而炒热度玩 solidjs 吃剩的玩意。vue3 吸收 react 的优点，并且设计上没有 react 带来的心智负担，这个方向相当好，甚至不少人放弃 react 转而去写 vue tsx 。而 vapor 我个人是不认可的，它的发展必定挤占大量开发资源，我手里的一堆 vue 项目都在考虑用 react 重构。yyx 懂开源，更懂炒热度，oxc 之类的项目也是如此。

@wwk #23 drizzle1.0 修复了大量 bug ，包括一堆迁移问题，正式项目可以等待 1.0 发布再转。
prisma 无论如何都不推荐用，很难想象多少公司被 prisma 推进坑里去了。

@ejin #7 来回看了半天，0-6 楼说的都是 react ，为什么突然冒出个 vue ，走错片场了吧？
Vapor 这种东西应该丢到 vue4 去搞，vue3 的一堆问题都还没搞定。
而且现在有人在意性能吗，反正我自己不在意。大厂用 react 多，react 性能那么差，性能真的有关系大厂早大量迁移到 vue3 去了。

我个人比较在意 vue 的一堆 typescript 相关问题，比如 defineProps 直接丢掉 undefined ，而官方对此表示这是合理的
const props = defineProps<{
a?: boolean
}>()
props.a
// ^? (property) a: boolean

直到支持了响应式解构才勉强算解决了这个问题，但是 defineProps 与 typescript 行为不一致依然是不合理的。
const { a = undefined } = defineProps<{
a?: boolean
}>()
a
//^? const a: boolean | undefined

vue 运行时再快有屁用，vue-tsc 比 tsc 慢了 5 倍，vue-eslint-parser 无法享受 typescript-eslint 的性能改进，vue 官方明确表示不会支持类型感知，只能社区自己搞了个勉强能用的，但是太慢，后端 lint 检查 12 秒，差不多体量的 vue 检查要 80 秒，慢了 7 倍，插件越多这个差距还会接着放大。

运行时性能差距，没人关心，用户也感受不到几十到几百毫秒的差别，相比之下 vue 与 typescript 的融合体验被 react 吊打。react 不会插件天天报错，升级版本换另一个报错，不会拖慢 CI/CD 检查，不会与 typescript 有不一致的行为，不会被 typescript-eslint 维护者指着鼻子说 Vue 社区对于支持 type linting 没有兴趣
https://github.com/typescript-eslint/typescript-eslint/issues/2865#issuecomment-742647474

别瞎搞这些有的没的。
服务器和数据库统一使用 UTC ，时间戳展示交给客户端。
datetime 没有时区，因此不建议用于有时区要求的场景。
如果想用 datetime 处理，设计接口时要额外传输时区信息，然后服务端转换成 UTC 时间，请求数据时转换成 Unix 让客户端自行处理。
当然这里存在一个问题，服务端完全丢失了该条数据的时区信息，如果业务有需要，再增加一个 timezone 字段。