有点old school，但我最爱的还是C。别的语言都在忙着替你遮丑，C倒好，直接把机器的底裤掀开给你看。我第一次真正搞懂"数组就是指针"那会儿整个人是恍惚的——原来a[3]和*(a+3)是一回事，内存地址、偏移量、数据结构，一下全在脑子里对上了。
C几乎没有隐藏的运行时。你写一行，它就老老实实变成几条指令，没有GC在背后偷偷摸摸，没有VM替你兜底。调一个segmentation fault，就是最硬核的计组现场教学：它冷冰冰告诉你，刚才访问的那块地址不归你管。这种痛记一辈子。
更别说C是地基。操作系统、编译器、嵌入式，往上数几乎所有现代语言都在它肩膀上偷懒。懂了C再看别的语言，你才明白它们替你省了哪些麻烦、又藏了哪些雷。
写C得对自己狠一点，但正是这种不替你兜底的诚实，让它最像计算机本身。
前两天改一个注册接口，用户名限制 20 字符。我顺手写了 len(name) <= 20，本地测试一切正常，直到有个用户起名叫"小明"后头跟了个笑脸 emoji，系统直接报超长。查了半天才反应过来，Python 3 的 len() 数的是 Unicode code point，一个 emoji 当一整个字符算；可数据库那边字段是 VARCHAR(20)，按字节存，那种 emoji 占四个字节，一下顶掉四个"字符"的额度。
更隐蔽的是前端显示。早些年我图省事用 substr 按字节截断，昵称里夹个 emoji，截断点正好落在它的第二字节，页面上立刻多出一块"豆腐"（U+FFFD 替换字符）。从某种角度看，这是我们把"一个符号等于一个存储单元"当成了默认前提。字符数、UTF
今天又被一个小坑绊了一下，说出来给各位提个醒。手头有个榜单要按数值排，数组大概长 [1, 2, 10, 3] 这样，我顺手 .sort() 一调，结果给我吐回来 [1, 10, 2, 3]。第一眼还以为自己眼花了。
其实 JavaScript 的 sort 默认不按数值比，而是先把元素 toString 转成字符串，再按 UTF-16 码元顺序逐个字符比。‘10’ 首位是 ‘1’，自然就排到 ‘2’ 前面去了。最阴的地方在于它属于 silent failure，不报错也不警告，页面该显示显示，数字却是错的。排行榜、价格、时长这类列表一旦直接排序，静默错乱能藏很久，排查时特别折磨。
解法说白了很简单也最易被忘：永远显式传比较函数 arr.sort((a,b)=>a-b)；嫌麻烦就用 Lodash 这类类型安全的工具，从源头别给自己留"忘了加比较器"的机会。这种 classic 的低级坑，踩一回就够记住了。
前阵子帮朋友看一个对账脚本，跑出来怎么都对不上，差了几分钱，maddening。翻了半天才发现，他图省事把金额直接用了 double。你看 0.1 加 0.2，在 IEEE 754 底下根本不是 0.3，而是 0.30000000000000004，肉眼看着一样，放进等号两边比较就是不等。嗯
更要命的是这种误差会滚雪球。他那个脚本里有循环累加，每笔利息再算一遍，几十万笔跑下来偏差就肉眼可见了。金融场景里"少一分多一分"是绝对不能忍的，可偏偏这种地方最容易埋雷，还埋得毫无声息。
其实
后来改成了整数，金额一律以"分"为单位走 long，显示的时候再除一百。需要更精细的，比如带汇率换算的，就上 decimal 那种任意精度的库，别拿浮点硬顶。说穿了特别简单，踩过一次才知道疼。你们有没有也在这上面栽过的？
混这个版有些年头了，老实说最离不开的居然是Python。不是因为它多漂亮，是它那个REPL把"猜想—验证"的循环压得太短。
早些年用别的语言，总得先把整段逻辑想周全，编译、跑、看结果、再回头改，中间那道摩擦特别消磨人。后来习惯在Python里敲一行回一行，试探一个数据结构、查一个边界条件，像跟机器实时聊天。debug也不再是"改—编译—跑"的三拍子，而是边问边答。
生态也实在省心。从抓网页到跑个小模型，pip一下基本都有轮子。想法落到原型常常就几行，注意力全留给问题本身，不必先跟语法细节搏斗。
其实
当然也有人嫌它慢、嫌它太松散。可对习惯性先把念头试出来再谈工程的人，它刚好卡在最舒服的那道缝里。
