多年迭代后Lalamove 的核心服务Yi经堆叠了上百个微服务、数千个数据库表以及无数废弃字段。粗略统计显示：

超过 30% 的业务代码Yi不再被任何请求触达；

100 多个旧字段仍然留在生产库中，却没有任何业务使用；

每一次发布dou伴随着「我怕删了关键代码」的焦虑。

这些“隐形负担”让新功Neng上线变得迟疑不决，也让新人阅读源码时倍感压抑。于是团队把「提升可读性」和「降低维护成本」列为今年Zui紧迫的目标。

在 Lalamove 的方案里“瘦身”并非盲目删改，而是一套闭环：

全量捕获方法调用频次：利用 HotSpot 虚拟机自带的 Service Ability模块，在每一次 JVM attach 时记录所有Yi加载方法的执行计数。

比对有流量与无流量的方法集合：借助开源分析框架 Spoon，将全量方法列表与实际产生业务流量的方法进行交叉，比出 “沉睡” 方法。

基于业务场景Zuo双向校验：采用 ShadowDB 与流量回放工具 llrepeater，对读写接口进行前后对比，确保删减不会破坏功Neng一致性。

持续监控与反馈：将关键指标上报至内部仪表盘，实现“实时提醒”，让每位开发者douNeng感受到自己的“清理贡献”。

SA 通过 attach 到目标进程来读取 JVM 内部结构，这一步会引发一次短暂的 STW暂停。因此团队选择在以下时机触发：

Pod 正在下线或即将销毁时；

手动切换到离线维护模式后；

CI/CD 流水线中专门预留的 “采集点”。

这种Zuo法既保证了数据完整，又把对线上业务的冲击降到Zui低。

Spoon Neng够遍历编译后的字节码并抽取出每一个类/方法的信息。我们先得到「全体方法」集合 A，再通过 SA 收集到「真实有流量」集合 B，两者取差得到 C随后对 C 中出现频率极低且关联废弃字段的条目进行标记。

ShadowDB 是从正式库复制而来的一套只读副本，它保留完整的数据结构但不含业务产生的新数据。通过让两套 pod 分别指向正式库和 ShadowDB，我们Ke以在同一时间运行两套完全相同的业务代码，只是底层数据来源不同，从而精准定位因 DB 字段删除导致的问题。

Dive‑In：全局扫描 — 使用 BigClean Scanner 在 IDE 中快速标记潜在死代码；随后运行 Spoon 脚本得到项目级别的方法清单 A。

Pulsar：收集热点 — 在每次 Pod 销毁前由 Kubernetes Hook 启动 SA Attach Agent，将运行期间累计的方法调用次数写入临时文件 B。

Differential：求交叉 — 通过自研脚本计算 A∩B和 A‑B，形成候选列表 C。

Triage：人工评审 — 将 C 按照调用频次、关联 DB 字段以及所属模块重要度排序，由经验丰富的 senior 开发逐项确认是否Ke以删除或迁移。

Migrate：影子验证 — 对需要删除或修改的数据表字段，在 ShadowDB 上先行演练，并使用 llrepeater 回放真实流量，对比返回结果是否保持 100% 一致。

Purge：安全删除 — 确认无误后提交 PR，CI 自动跑单元测试 + 集成测试，同时检查 MyBatis 拦截器报告中是否仍有残留引用。

Cascade：监控告警 — 删除后继续收集 SA 数据，Ru果某个原本沉睡的方法意外出现调用峰值，则立刻触发 Slack/Teams 告警，让团队及时回滚或补丁修正。

Evolve：经验沉淀 — 将本次清理过程及关键指标写入内部 Wiki，形成 SOP，让下一轮“大扫除”geng高效、geng安全。

Lalamove 在一次完整迭代中，通过上述流程共定位并清理了约 9 万行冗余代码，其中包括：

约 120 条Yi废弃但仍被查询的 SQL 片段；

Kafka 消费链路中多余的序列化/反序列化步骤；

Redis 缓存键名中遗留的不再使用前缀共计 45 条；

text 前置指标： - 方法总数 : 12 842 - 活跃方法数 : 8 735 - 沉睡方法数 : 4 107

text 清理结果： - 删除无引用类 : 312 - 删除无引用函数 : 4 021 - 废弃 DB 字段 : +108

geng重要的是通过 ShadowDB 对比和 llrepeater 回放，两次关键订单查询接口均未出现任何响应差异，这直接证明了削减措施对业务安全性的零影响。项目结束后研发团队报告说「每周上线窗口从原来的两天缩短到了半天」，而且新成员上手阅读源码所需时间下降约 40%。这些数据足以让人热泪盈眶，也足以证明「技术债务」真的Ke以被踩平！

定期埋点检查：将 SA 数据收集纳入每日例行任务，每周生成一次“活跃度报告”。这样，即使新功Neng加入，也Neng第一时间发现潜在冗余点。

CI/CD 强化审查：把 MyBatis 拦截器输出作为 lint 检查的一环，让 PR 提交时自动提示可Neng涉及废弃字段的 SQL。

文档同步机制：任何数据库结构变geng必须同步geng新对应的数据字典，并在变geng完成后一周内通过 BigClean Scanner 验证相关代码是否Yi同步迁移。

文化渗透：每月举办一次「代码瘦身小讲堂」，分享成功案例和常见坑点，让大家把「删掉」当成一种积极创新行为，而不是恐惧之源。

监控预警阈值：当某个Yi标记为沉睡的方法突增至日均调用次数超过阈值，系统自动发送告警并打开 issue 跟踪根因。

Lalamove 的这场代号为「大扫除」的大行动，不仅让系统负载下降了近两位数，geng让研发文化焕发出了新的活力。它告诉我们：「技术债务」不是不可逾越的山峰，而是一块块Ke以用数据说服自己去搬走的小石子。只要坚持用Spoon + SA + ShadowDB + llrepeater 这套闭环，你也Neng把自己的服务打造成一支轻盈而又强大的快跑队伍。

愿所有正在为「代码肥胖」苦恼的小伙伴，douNeng在下一次部署前kan到一行行geng加干净、geng加有温度的源码！ 🚀💡