协议旧指令该不该删？4 个检查决定删除还是保留兼容
一句话: 协议旧指令不是一律删除：先确认新指令是否完整替代、是否已有外部使用者、删除是否影响升级兼容、能否回退；四项都通过才删，并同步代码、文档和测试。
适合谁读：协议/接口有新旧两套并存，纠结"要不要删旧版"的嵌入式工程师。
先用这 4 项检查决定，不要凭"感觉"删
| 检查项 | 通过条件 | 不通过时怎么做 |
|---|---|---|
| 功能替代 | 新指令覆盖旧指令的输入、输出和异常路径 | 保留旧指令或先补齐新指令 |
| 使用范围 | 没有外部客户端、脚本或已交付版本依赖旧指令 | 建立废弃期，文档写清迁移时间 |
| 兼容影响 | 删除不会破坏升级、存量配置或固定协议解析 | 先做兼容层或版本协商 |
| 回退证据 | 有可定位的版本记录和最小回归测试 | 先补测试与回退说明 |
四项都通过，删除才是减少维护成本；只要有一项不通过，先标记为"废弃但保留"，不要直接移除。删除后的最小验收是：编译通过、替代指令的正常与异常路径通过、协议文档里不再留下旧入口。
text
删除前：搜索旧指令的解析、调用、测试和文档引用
删除后：编译 + 跑替代指令测试 + 重新搜索旧指令
预期：只剩迁移记录；若仍有调用点，停止提交并补齐迁移背景：两套指令做同一件事
设备协议演进中，出现过一批"临时指令"------当时为快速支持某个功能加的，功能验证完又有了更规范的正式指令。新旧两套指令做的是同一件事，只是命令号不同。
留着它们也没"错"，但代价在别处：
| 代价 | 具体表现 |
|---|---|
| 固件 | 同一功能两份 case，改一处忘另一处 |
| 文档 | 协议文档两头写，还容易不一致 |
| 测试 | 每条指令测一遍，工作量翻倍 |
| 客户 | 上位机同事不知道用哪套，两边踩坑 |
为什么想留着：害怕"万一有用"
不敢删的典型心理："万一以后要用呢？" 但回头想------真有需求，从 git 历史里随时能翻回来。代码删了能找回，文档删了也能找回，怕的不是删，是"删了还要重新写"的麻烦，而 git 早就解决这个麻烦了。
删了之后
删掉旧指令，只留新指令：
| 项 | 删之前 | 删之后 |
|---|---|---|
| 固件逻辑 | 两套 case | 一套 |
| 协议文档 | 两个命令号 | 一份说明 |
| 测试 | 每套跑一遍 | 一遍过 |
| 客户对接 | "用哪个？" | 没得选，用新的 |
功能上没有任何损失------新指令早就覆盖了旧指令的全部功能。维护成本直接减半。
什么情况该留
不是所有旧接口都该删，判断标准：
| 情况 | 处理 |
|---|---|
| 新指令完全替代旧指令 | ✅ 删，没理由留 |
| 有客户在用旧指令 | ⚠️ 过渡期保留，文档注明废弃 |
| 旧指令有独特功能 | ✅ 保留但文档写清楚 |
| 删除会影响 Flash 布局/升级 | ⚠️ 确认兼容性再动 |
关键区别："没人用"和"有人用"是两种决策。内部协议、没发布出去的，直接删；发布出去的，走过渡期。
删的时候注意三件事
- git 提交前先编译验证：删完编译必须 0 错误 0 警告，删错了立刻能发现
- 提交信息写清楚：哪个指令删了、被哪个替代，方便以后查
- 文档同步删：协议文档里旧指令说明一起删，别只删代码------不然文档和代码又打架
总结
- 新指令能替代的旧指令，果断删，别留着"以防万一"
- 代码删了能找回（git），留着才是长期的维护负担
- 内部协议直接删；发布过的走过渡期
- 删完：编译验证 + 文档同步 + 提交信息写清
代码不是古董，越攒越值钱；是负债，越留越重。
有用的话点个收藏 ，下次纠结旧接口删不删，按这个标准判断。有问题欢迎评论区交流，看到了都会回。
相关文章 ：删死代码不是一行行找------从根节点往下砍------要定位旧指令残留调用时继续看；git几个救急命令------恢复文件、查看历史、删追踪------需要核对或恢复历史版本时继续看。