2024年1月18日接口迁移兼容日志
一套老报表接口，PHP 5.6 写的，跑了七年。要迁到 Node.js，代码本身两三天就译完了，真正花时间的是「别把谁弄断」。
先查谁在调
没人说得清这个接口被哪些地方用。文档停在 2019 年，列了 2 个调用方，明显不全。
办法很笨：拉半年 Nginx 的 access log，按这个 path 过滤，把 query string 拆开统计。结果找出 3 类带旧参数的请求：
- 一个内部的定时任务，还在传 type=1 这种老枚举。
- 一个客户自己做的看板页面，参数名拼错了但一直能用，PHP 那边做了容错。
- 最意外的一个，来自一台办公电脑的 Excel 宏，用 Web 查询拉数，User-Agent 是 Office 那串。
第三类要是漏了，上线第二天那边报表就空了，而且没人会想到去查宏。
兼容层怎么留
新接口参数重新设计过，但外层留了一个适配：旧参数照收，内部映射成新字段；type=1 这种老枚举翻译成新枚举；拼错的那个参数名也留着，标了 deprecated。
响应 JSON 的字段名和层级一点没改。改响应比改参数危险得多，下游多半直接按下标取值。
另外在每个请求里记一行日志：原始参数、识别成哪类调用方、走的兼容分支没有。跑了两个月，我们照着这张表一个个去联系，把定时任务和看板迁到新参数。Excel 宏那个没动，客户说那台电脑还要用两年。
灰度那段
两套并行了 3 周，Nginx 按 cookie 分流，跟之前灰度一个套路。旧接口留了 7 天才关，关之前先看日志确认没有请求再进来。
有个小坑：Node.js 那边默认把数字精度按 JS 处理，报表里有个 17 位的单号，返回给 Excel 时末尾变了 0。发现后改成字符串返回，才对上。这个 PHP 时代不会遇到，是换语言带来的。
现在
兼容层还在，代码里一个 switch，不到 30 行，注释写着「别删，Excel 还在用」。等那台电脑退役再说。
迁移这事，写代码是最短的一段。
