你把 mutable 的东西当 prop 传给 children 时就容易出问题了，想想下 children 里面 useEffect(...,[theObject])

@ipwx 规模小不代表业务简单🤣如果他的业务逻辑极大依赖数据库特性，换 sqlite 就全得自己写了

正常不正常看你业务需求啊，访问少的站或者内部系统 1000 每天很正常，用这个衡量 ms sql 合不合适没啥意义。
还有人说用 sqlite/MySQL 的…差的功能全都自己写代码补吗？

@Features 事务虽然会并发执行，但会按照设定的隔离等级，利用锁和多版本记录等机制保证正确处理你面对的这种问题，最严格的 Serializable （可序列化）隔离等级理论上会保证执行结果和看起来一个一个非并发的执行完全一致（当然只是理论上，实际中不同的数据库在一些细节上还是会有些不同的偏差，需要查阅数据库文档，不过感觉你现在不需要关心这些）。
具体比如如下这个例子：

```sql
select 账户 ID, 余额 from table_name where 余额 >= 100;
update table_name set 余额 = xxxxx where 账户 ID = xxx;
```

在（ PostgreSQL 数据库中）隔离等级为 RR 或 SI 时，慢一步的会话可能会在 update 时报错，事务 rollback 。MySQL 在 RR 下不会报错失败(Lost update) 但在 SI 下也会不能提交。

（所以 PostgreSQL 好！:)

哦，如果完全不会用事务，那啥隔离等级也没用···这倒是忘了

如果你对事务不太了解，建议切换至 Serializable 隔离等级

自己搭数据库呗，反正业务也不太大

@Jinnyu 听说 12306 用的是 PG 的商业方案？

@yazinnnn 好耶！

URL 里大小写敏感太不友好了，不妨 system-maintaining 或者 system_maintaining 更好

@ChaosesIb 当然，我针对的是你话中的“对线”，对线可不是沟通～

@FrankHB 如果你认为跑到对应 issue 区域开骂是合理的，请自便

@ChaosesIb 看一遍开源协议，要么 fork 要么忍着

@pengtdyd 比如说创建资源（订单）的接口，如果不增加额外的 限制，不幂等才正常吧

api 加个 uuid 和时间戳，比较时间范围和 uuid 重复

传统 API 模式的好处是 API 相对固定，查询模式往往派生自 API ，也相对固定，便于实现和优化； graphql 这种会导致查询模式完全由前端传递，后端进行限制和优化难度陡增。想想是手动实现优化与一个 SQL 等价的查询容易还是编写一个通用的查询优化器容易～ dataloader 相对缓解这个问题，但是彻底解决我看够呛

dataloader 也不能解决全部问题，只是粗暴的把 key 聚合起来一次查询而已。整体来看迁移成本太高了，将整个查询控制交给前端，前端给出啥样的查询完全不可控，很容易把后端搞死······

能不打破就别打破，但有时候也没办法