Go 的有点个人感觉在部署构建（傻瓜交叉编译太香了）和基础工程工具上（比如 go fmt ），但是一旦牵扯到 CGO ，这些优势就大打折扣了。其他方面 Go 没什么出彩的地方。感觉拿来做一些命令行工具和基础设施是合适的，写业务就算了，心智负担。

@LotusChuan go 的 rpc 是什么？

explain (analyze on, timing on)看看慢在哪呗

setter & getter 是 Java 没有 property 导致的，<del>就像 Go 一样，写编译器的省事了，程序员就费事了</del>，直接暴露 field 是不合适的。

看来是缺币了

感觉这东西的竞争对手并不是 Spring···这不是一种东西啊

docker run 是一大堆操作的集合。先创建一个容器，然后启动它，用完了再删除它

写 SQL 还得是 DataGrip ，当然企业版都集成了

你把 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 更好