工程认知 on Zampo Blog

别再问学 Java 还是 Go 了，英语才是程序员的底层入口

Wed, 03 Jun 2026 20:35:00 +0800

线上问题卡住，中文搜索结果翻来覆去是几篇搬运稿。

标题不一样，内容差不多。有人把官方文档机翻一遍，有人把别人的答案洗一遍，还有人把一段过时配置包成“终极解决方案”。你照着试，报错没少，时间没了。

换成英文关键词再搜，GitHub issue 里已经有人把版本、原因、绕法和维护者回复写清楚了。

很多程序员焦虑“下一门语言学什么”：Java 还值不值得学，Go 会不会更有前途，Rust 是不是未来，Python 会不会被替代。

这些问题当然重要。

但它们不是最底层的问题。

我越来越觉得，对程序员来说，英语才是最容易被低估的“计算机语言”。不是说英语能替代 Java、Go、Rust，也不是说会英语就自动会编程。

真正的意思是：英语决定你能进入多大的信息网络。

不会英语，不是在少学一门语言，而是在少进一个技术世界。

你缺的可能不是下一门语言，而是更大的答案池

编程语言本身只是工具。

Java 能做，Go 能做，Python 能做，Rust 也能做。它们的差异当然存在，但很多时候，一个问题解决不了，并不是因为你没换语言，而是因为你对手里的语言、框架、运行时、生态和真实坑点理解得还不够深。

这时候最要命的不是“不会写代码”。

是找不到答案。

中文技术社区不是没有好内容。相反，很多中文作者写得非常认真，也有大量高质量笔记、教程和源码分析。但问题在于，中文技术内容的整体密度不够稳定。

尤其遇到新技术、小众库、奇怪报错、复杂版本冲突时，你很容易进入一个贫瘠的信息池：几篇搬运稿、几个半截答案、几条没人接的评论。

英文世界的优势，不只是“资料多”。

它更像一张已经运转很久的答疑网络：Stack Overflow 处理编程问题，Server Fault 处理运维问题，Database Administrators 处理数据库问题，Ask Ubuntu 和 Unix & Linux 处理系统问题，Software Engineering 讨论软件项目和工程判断。

再往外，还有 GitHub issues、GitHub Discussions、官方论坛、Reddit、Discord。很多时候，你不是在读“教程”，而是在看问题如何被发现、争论、定位、修复。

这两者差别很大。

教程给你一个结论。issue 给你一条现场。

结论通常是干净的：改这个参数、换这个版本、加这一行配置。现场往往没那么好看。有人说是网络问题，有人说是权限问题，有人贴了最小复现，有人指出某个 minor version 才触发，还有维护者在最后补一句：这个行为不是 bug，是设计如此。

你真正长经验，常常是在这些不干净的地方。

因为工程问题很少按教程里的顺序发生。它们总是带着版本、环境、历史包袱和人的误判一起出现。你只看二手教程，就只能看到被整理过的结果；你能读英文现场，才有机会看到答案是怎么被拧出来的。

一个成熟程序员真正需要的，往往不是别人把答案喂到嘴边，而是能进入现场，看别人怎么拆问题、怎么排除错误、怎么在版本约束里做取舍。

英语的价值就在这里。

它让你不必总等别人把现场剪辑成二手教程。

只等翻译，就默认自己晚几个版本

翻译当然有价值。

没有大量中文翻译、中文教程、中文笔记，很多人一开始根本进不了门。我自己也受益过很多中文资料，所以这不是要否定中文社区。

但做技术的人必须承认一件事：翻译解决不了所有问题。

MySQL 千疮百孔，为什么没人能替代它

Wed, 03 Jun 2026 18:21:00 +0800

技术评审会上，最尴尬的不是没人知道 MySQL 有坑。

最尴尬的是，所有人都知道它有坑，最后还是选它。

有人说 PostgreSQL 更严谨，有人说 MySQL 的外键、触发器、枚举、事务边界都要小心，有人甚至能现场背出几个历史遗留问题。会议开到最后，大家把迁移成本、线上经验、云厂商支持、团队熟练度、历史 SQL、ORM 方言、排障手册一摊开，气氛就变了。

问题从“它好不好”，变成“出了事谁负责”。

这才是 MySQL 最有意思，也最残酷的地方。

它当然不完美。甚至可以说，它身上有一堆非常不优雅的历史包袱。但它仍然是开源关系数据库世界里最强的默认选项之一。MySQL 官网到今天还把自己称为 “The world’s most popular open source database”，DB-Engines 这类榜单上，它也长期站在最靠前的位置。

所以真正值得问的，不是“MySQL 到底烂不烂”。

这个问题太容易变成情绪表态。

真正值得问的是：一个到处有补丁、有边界、有反直觉行为的软件，为什么还能变成事实标准？

MySQL 赢的不是优雅，而是默认值。

坑不是最可怕的，悄悄返回结果才可怕

数据库最让人害怕的 bug，通常不是直接报错。

报错至少诚实。它告诉你：这里不行，停下来处理。

更危险的是那种看起来能跑、能查、能返回结果，但行为和你脑子里的模型不一致的东西。你以为自己在和一个严肃的系统打交道，结果它在某些地方像脑筋急转弯。

比如 ENUM。

很多团队会用它表示状态、尺码、等级：

1
2
3


CREATE TABLE products (
 size ENUM('S', 'M', 'L', 'XL')
);

按直觉，S、M、L、XL 是一组字符串。你排序的时候，也许会以为它们会按字母顺序走。但 MySQL 官方文档明确说，ENUM 的排序默认基于它在定义里的索引位置。也就是说，ENUM('b', 'a') 里，b 会排在 a 前面。

这不是没人告诉你。文档里写了。

问题是，业务开发者每天脑子里装的是订单状态、库存、优惠券、用户权限，不是每个数据库类型的历史脾气。一个字段明明长得像字符串，很多时候也像字符串一样被使用，但在排序时又按定义顺序来。你当然可以说“这是文档行为，不是 bug”。

可工程里的危险，恰恰经常藏在这种地方。

MySQL 是蠢是坏，还是又蠢又坏

Wed, 03 Jun 2026 16:34:00 +0800

你只是改了一下订单状态，结果买家表被锁住了。

订单状态在订单表里。买家信息在买家表里。按正常直觉，这两个动作不该互相打扰。外键要保护的是买家 ID 这种关联字段，不是订单状态这种业务字段。

但 MySQL 里事情偏偏就这么发生了：因为订单状态和买家 ID 出现在同一个 composite index 里，更新订单状态时，父表也被卷进了锁行为。

这不是“开发者不会用数据库”的问题。

真正别扭的地方在于：你很难从数据库基本原理里推导出这种结果。它不是那种“虽然复杂，但想通后合理”的设计，而更像一个长期使用者不得不记住的禁忌：这个功能别这么用，不然会出怪事。

于是，MySQL 的争议就不该只停在“它有没有 bug”。

更值得问的是：当一个工具足够普及，又把一些本来该可靠的能力做得反直觉，它会不会反过来改变一代程序员对数据库的想象？

烂工具最可怕的地方，不是它难用，而是它会重写行业常识。

“懂行的人都不用”这句话，本身就很可疑

很多 MySQL 使用者都听过一套经验：

Foreign Key 少用，Trigger 别用，Enum 少碰，Composite Index 别乱搞。

如果这句话只是提醒大家别滥用复杂功能，那没问题。工程里确实有很多功能不是“能用就该用”。外键会影响写入路径，触发器会增加隐式逻辑，枚举会带来迁移成本，复合索引也可能让优化器选择变复杂。

但问题是，这套经验在很多团队里已经变味了。

它不再是“理解代价后谨慎使用”，而是“懂行的人都不用”。

这就很奇怪。

Foreign Key 本来是关系数据库维持 referential integrity 的基础能力。Trigger 本来是数据库表达约束和副作用的一种方式。事务本来是数据库区别于电子表格的核心能力之一。你当然可以因为项目规模、团队习惯、迁移策略而不用它们，但如果一个生态里大量老手都把这些能力当雷区，那就说明问题不只是“用户没学好”。

有时所谓最佳实践，只是长期踩坑后的创伤反应。

这也是 MySQL 最有杀伤力的地方。它不只是让你踩坑，它还会让踩坑的人长出一套非常自洽的解释：数据库本来就不该管太多，业务逻辑都应该放应用层，表只要能 CRUD 就够了。

听起来很务实。

但这套务实背后，可能藏着一种被训练出来的贫瘠。

第一个坑：索引和外键不该这么纠缠

我们把视频里的例子简化一下。

一个订单表有买家 ID，也有订单状态：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


CREATE TABLE buyers (
 id BIGINT PRIMARY KEY,
 name VARCHAR(100)
);

CREATE TABLE orders (
 id BIGINT PRIMARY KEY,
 buyer_id BIGINT NOT NULL,
 status VARCHAR(20) NOT NULL,
 FOREIGN KEY (buyer_id) REFERENCES buyers(id)
 ON UPDATE CASCADE
);

如果你更新的是 buyer_id，数据库需要检查父表、维护关系完整性，这很正常。