开发与 Web
这一类文章的共同点是：规则本身很短，但「在什么位置适用哪条规则」决定了对错。URL 编码只有一句话可以说清楚，可一旦搞混「编码整条 URL」和「编码一个参数值」，签名就会永远对不上；HTTP 状态码也就几十个，真正难的是 401 和 403 该报哪个、409 和 422 的边界在哪。
所以这里的写法都是先给判据、再给结论：什么情况下该用哪个，用错了会以什么形式表现出来。排查类的文章会给出顺序 —— 从最容易忽略的开始查，而不是从最常见的开始猜。
- 接口调不通？按这个顺序排查从 curl 到浏览器请求，接口失败的原因九成落在这五处：Content-Type、鉴权头、CORS 预检、编码和超时。给出可照着走的排查顺序，以及怎么把 curl 快速变成代码。
- 进制转换：十六进制、补码与浮点误差十六进制为什么总以成对出现、负数在计算机里怎么表示、0.1+0.2 为什么等于 0.30000000000000004，以及 JS 里大整数精度丢失的边界在哪。
- cron 表达式怎么写（含常见写法速查）从 5 段字段的取值范围讲到 , - * / 四个特殊字符，给出十几个可直接抄的表达式速查表，并说明"日"与"周"的 OR 语义、Quartz 的 6 段差异，以及时区、重叠执行和输出重定向这几个真实坑。
- HTML 转义怎么做才不出 XSS 漏洞转义不是「把尖括号换掉」这么简单。讲清五个必须转义的字符、文本/属性/JS/URL 四种上下文各自的规则，以及为什么「存的时候转义」是错的、富文本只能白名单过滤。
- HTTP 状态码：真正需要记住的那些按"会不会影响客户端行为"筛选出一二十个必须掌握的状态码，讲清 401/403、301/308、302/303/307、502/503/504 这几组最容易被混淆的区别，以及重试语义和常见的错误用法。
- 开发者最常用的正则表达式写法按联系方式、数字金额、日期时间、中文字符、证件编码、网络文件、账号密码七类，给出 30 多条可直接复制的正则表达式；并讲清贪婪与惰性、捕获组与断言、多行标志的区别，说明 ReDoS 是怎么被嵌套量词触发的以及怎么改。
- SQL 怎么写才好看：格式化与命名约定给出一份可直接落地的 SQL 排版规范（关键字大写、主子句顶格、JOIN 缩进、CTE 替代深层子查询）和数据库对象命名约定表，并说明哪些约定是审美、哪些会真正影响正确性和可维护性。
- Unix 时间戳完全指南：秒、毫秒、时区和各语言对照Unix 时间戳是从 1970-01-01 UTC 起算的秒数且不含闰秒。这篇给出 JS/Python/Go/SQL 的互转写法、秒与毫秒的判别方法、2038 年问题与存储建议。
- URL 编码：%20、加号与双重编码的坑空格到底是 %20 还是 +、encodeURI 和 encodeURIComponent 差在哪、为什么中文变成了三个百分号、签名怎么总是对不上。把 URL 编码的规则和事故一次讲清。
- YAML、JSON、TOML 配置文件怎么选从注释、类型系统、嵌套表达和可维护性四个维度对比三种配置格式，给出 YAML 的隐式类型坑、JSON 的适用边界和 TOML 的强项，以及具体的选型建议。
这一类常见问题
为什么这些规则看起来都对，实际用起来总出错？
因为规则总有「取决于上下文」的部分。同一个字符在路径、查询串、请求体里含义不同，同一个状态码在不同网关下被改写。文章里会标明适用位置，遇到对不上时先确认自己处在哪个上下文。
文章里的结论可以当规范用吗？
格式类结论（编码、进制、时间戳）可以直接用，它们由 RFC 或平台文档固定。行为类结论（网关怎么改写、浏览器怎么缓存）会随实现变化，文章标了依据，遇到差异以实测为准。