@ragnaroks #26 对于计算密集型场景，nodejs 可以把这部分任务交给 napi-rs
就我个人体验来说，性能是一个复杂项目中最不重要的指标

@iorilu 没有必要再学一门"后端语言"。
除非公司项目硬要扣一点性能，monorepo+ts+全栈是 AI 时代性价比最高的做法。
目前公司的所有后端项目都用 ts 重写了，我们对性能要求很高，但至今为止还没碰上 nodejs 带不动的场景，就算 nodejs 性能差一点也可以换 bun 。

@duuu #9 外国的信用卡基于"信用"本身，付款人可以取消支付，因此免密信用支付才能推行下去，被意外盗刷了用户是可以不认的。
而且这也不是盗刷，用户授权给游戏公司，游戏公司生成一笔交易订单推送给支付渠道，支付渠道验证后批准这笔交易，在支付渠道看来，这是一笔正常的交易。
不管国内还是国外，都是一模一样的流程，如果这事发生在中国，就是绑定支付宝/微信的用户授权给游戏开通免密支付，结果发现自己的支付宝/微信余额被莫名扣减。

> 商家一定无法控制扣谁的钱
这是错的，商家能控制扣谁的钱是免密支付的基石。
用户授权给商家，那么就相当于把自己钱包的部分管理权授予给商家，商家拿到你的令牌可以请求平台进行交易，平台只会验证密钥、令牌、余额等信息，对支付平台来说，它不会也不能去验证这笔钱是不是你发起的。而在这个案例中，是商家发错信息了，平台依照请求忠实地促成这笔交易，第一过错是发错东西的商家，第二过错是把令牌授予商家的用户，支付平台在这里没有任何过错。
一般来说，碰上这种事支付平台会狠狠地罚商家一大笔钱，因为它的信誉受损，信誉或者信用是支付平台能长久运营的基石。

拿 xxl-job 和 airflow 比较很奇怪，它们是完全不同的东西。
xxl-job 踩在了过于简单与过于复杂中间，且对 javaer 友好，让一些屎山项目能够顺利迭代下去。
xxl-job 之类的工具是基于微服务且明确违反微服务设计哲学的实用性妥协方案，它实际反映出很多公司是为了使用微服务而使用微服务，而不是需要使用微服务而使用微服务，如果是后者居多，那么并不需要这么一个"分布式调度中心"。
对于更复杂的分布式调度，不应该采用高入侵性方案，而是应该搭建一个调度平台 https://github.com/temporalio/temporal

@hellojukay 轮着来难道不是指一家人轮流去娘家/婆家吗，我不理解你这"一个人"是什么个意思。
我姐和姐夫就是这样的，我没觉得有什么问题。

失业金没影响，进小程序会告诉你能领多少个月
确定入职下家公司后要申请停止领取，不然公司交不了医社保

你的反感是对的，但正确方式不是抵制它，而是控制生成的代码的质量。
vibe coding 主要有两个作用远胜于传统编码：1. 快速出 demo 、快速使用从未接触过的库; 2. 强大的静态检查。
除此之外，vibe coding 并没有解决编程的实际复杂度，它只能作为开发人员的一个工具，而是否能用好工具，与工具本身无关。

@liminany1 因为 99%中药对 99%病人没有作用，爱吃就多吃点。

愚蠢的人类，妄想从随机数里找到规律

我说个暴论，凡是用得上 EventEmitter 的项目，99%是屎山

对业务很了解和自己开店没有关联。
我确实对跨境电商很了解，但从没有自己开店的想法，正是因为太了解了。

以 drizzle 的数据库 schema 为第一优先级，在此之上派生下一级的用于接口校验、表单验证的 schema 。
现代化的 typescript 工程，要严格遵守 DRY ，不允许在任何地方出现多次重复定义，分离数据库层与业务层实际上与复用逻辑并不冲突，没有写两遍的必要。
无论何时，应该只有一个唯一来源，应用于整个项目，包括前端以及所有中间件服务，并强制保证运行时类型与 ts 类型完全等同。

基于这个理论，不应该直接使用 createInsertSchema 和 createUpdateSchema ，因为它们也是在重复定义并不明确的类型，应该封装一个方法统一给所有下一级 schema 使用。

它可能长这样 const createSchema = (table,labels)=> createInsertSchema(table).pick(labels)
具体代码不贴了，有一些类型体操，需要保证输入限制以及 pick 生效

举个例子，我定义好一张表
export const userTable = pgTable('user', {
...baseTable,
username: varchar({ length: 32 }).notNull().unique(),
password: varchar({ length: 64 }).notNull(),
})
然后这么使用
export const userLoginSchema = createSchema(userTable, {
username: (s) => s.min(4),
password: (s) => s.min(6),
})
因为返回的是一个 zod 对象，可以按照业务逻辑进行 extend 不在数据库中的其他参数，或者根据业务进行覆盖

第一参数接收一个数据库表，以此限制第二参数输入的键名，value 是一个函数，参数是经过 drizzle-zod 生成后的 schema
drizzle-zod 会为 varchar({ length: 32 }) 这样的定义自动生成 z.string().max(32)，但是它不会限制最小长度，因此派生的 schema 需要在原来基础上进行补充，或者也可以直接传入一个 zod 对象覆盖。

不应该对业务层暴露一大堆的 optional ，而是严格限定你只能传递什么东西过来，它要么必须有值要么禁止传递，从数据库层一层一层往下传递到所有涉及到的地方，一直到达前端表单，这才是 schema("契约")的正确用法之一。

还有个地方需要注意，这个 schema 不能直接在 monorepo 中被前端/中间件引入，因为包含完整的数据库模式以及用不到的大量运行时函数，直接 import 大概会打包出两百多 k ，需要使用 json-to-zod + zod-to-json(zod4 最新版已内置) 等变通方法，监听 schema 文件自动生成一个新文件并 export 给其他项目。当然因为无法序列化函数，所以 refine 等功能都用不了。

此外我对 createSchema 进行了大量改造，包括强制传递元数据，并在路由/表单通过包装 safeParseAsync 函数解析出适合人类阅读的提示信息：'用户名长度最低为 4 位'、'密码长度最低 6 位'、'缺少 xxx 字段'、'xxx 格式错误'，其中'用户名'和'密码'就是我要求传递的提示文本，它同样只能定义一次，还可以进行 i18n 改造，所有其它信息可以通过遍历 code 、origin 、input 等进行填充，社区里大量使用的 zod i18n 库是一个不理想的变通方法，但图省事也可以去用。

@shintendo #24 eslint 已经弃用了 allow-null ，可以传递一个对象例如 ["error", "always", {"null": "ignore"}] 进行排除。https://eslint.org/docs/latest/rules/eqeqeq
我认为 == null 是个不太好的编程习惯，带有隐式判断
我自己无论何时都会显式编写 if (x === null || x === undefined)
不过也没用上几次，在有了 ?. 和 ?? 后，几乎不存在需要使用 ==null 的场景

假榜，两个春熙路都没看见

@Kirkcong #68 各大中小厂商的文档只能用狗屎来形容，如果再打开官方提供的 SDK 看一下源码更是不堪入目。

const deps = getDeps.call(store, store);
这样的实现必须手动在 getter 写一次，@memo 指定依赖列表，完全依赖约定，把 react 的糟粕带了过来。

useStoreSelector 是通过猜测用户访问了什么属性调用 trackGetterAccess 增加引用计数，有多脆弱我就不说了，至少 StrictMode 会错误计数。此外没处理好竟态条件。

另外 View 层反向控制 Model 的缓存过于反模式，只要没有 React 组件在查看属性，就会直接删掉缓存。
Immer 混搭 weakMap 过于奇葩。

一堆 any ，看一半就没耐心看下去了。

函数式的重点在于不可变更新。

> 费力地模拟着面向对象
不费劲，闭包是穷人的对象。

你说对象=状态+行为

更准确地说
对象=原型链+状态+行为
闭包=状态+行为

get() 和 this 有本质上的区别，this 只会带来 bug 和心智负担。

> 它是“二等公民” ：你必须显式地调用它 get()，而且它打破了 JS 引擎对 this 的自然优化。
这是我 2025 年听到最好笑的笑话，比这个还好笑 /t/1177228