你想往一份固件镜像里新增一个驱动模块——不是替换已有的某个，而是插进去一个原来没有的。你手头有一个厂商提供的官方工具，看起来正好能做这件事。试了几次都失败，最后翻开它的用法说明才发现：它的设计里根本没有"插入"这个动作。
现象
- 用官方工具往固件里插入一个模块，怎么调都不成功；
- 工具不报"功能不支持"，只是结果不符合预期——镜像里没多出那个模块；
- 你以为是自己参数写错了，反复调整参数组合，浪费了不少时间；
- 最后去看用法说明，才看到它接受的输入是"镜像 + 标识 + 段类型 + 内容"，压根没有"往哪里插"的位置概念。
根因
根因是：这个工具的设计意图是"替换已有模块"，不是"新增模块"。
看它的参数结构就能读出来：
<工具> <镜像文件> <模块标识> <段类型> <内容文件>
这是一组"用内容去替换某个已存在的标识对应的段"的操作——它需要你先指出一个已存在的目标（标识 + 段类型），然后拿新内容覆盖它。整个过程里没有"插入位置"这个概念，因为它的模型里就只有"替换"。
为什么做不到插入？因为插入比替换复杂得多。替换是等量覆盖：新内容占的空间就是把旧内容挖掉腾出来的空间，镜像的整体布局不需要变。而插入要给新内容腾地方，会导致：
- 后续所有模块的偏移全部要往后移；
- 所在卷的头信息（大小、各文件偏移）要重算；
- 可能触发卷拆分（如果空间不够）或需要重新对齐；
- 相关的校验值要重算。
这些是"替换"不会遇到的问题。工具的作者把能力边界定在"替换"，是一个取舍，不是 bug。边界就写在它的用法说明里。
解决
接受"官方工具做不到插入"，改用自己写脚本按固件结构注入。
脚本要做的事，比"替换"多出"腾空间 + 修偏移"这一整块：
1. 解析镜像结构（固件卷 → 卷内文件/模块，记下每个的偏移、大小、类型）
2. 确定插入位置与所需空间
3. 为新模块腾空间：
- 若所在卷有剩余空间，直接在末尾追加
- 不够则考虑放入别的卷，或处理卷的重新划分
4. 写入新模块内容 + 它的文件头（GUID、大小、类型、属性）
5. 修正受影响的元数据：
- 卷头的大小与文件数
- 卷内后续文件的偏移（如果是中间插入）
6. 重算需要重算的校验值
7. 用解析工具重新读一遍新镜像，确认结构完整、新模块在位
务实一点的做法：能替换就尽量替换。 如果目标是"让固件加载某个驱动"，很多时候可以用一个已有的、不需要的模块作为替身，把它的内容换成你要的——这样就退回成"替换"，官方工具直接就能干。想清楚"我到底需要新增一个模块，还是只要这段功能被固件加载"，往往能把工作量砍掉一大半。
延伸与预防
这条坑的通用教训是：工具的能力边界写在它的用法里，先读用法再动手。
很多人拿到工具的第一动作是"先试一下"，而不是"先看看它接受什么输入"。对简单的日常命令，这样最省事；但对结构性的、破坏性的操作（改固件、改分区、改数据库结构），先读用法能省下的是成倍的时间——更重要的是，能避免用错工具造成的损坏。
一个可操作的次序：
- 读用法（usage / help / README），尤其看它接受哪些参数。参数列表往往比文字说明更能反映能力边界——缺哪个位置参数，就说明它做不了那件事。
- 明确你的操作性质：是替换（等量、不动布局）、插入（要腾空间、动偏移）、还是删除（要回收空间）？这三种在底层是三个不同量级的工作。
- 判断工具是否覆盖了你的性质。 不覆盖就换工具，或者自己写。别试图"用参数凑出"工具本来就不支持的操作。
- 换一条更省的路。很多"非要插入"的需求，其实可以转化为"替换一个已经存在的、不需要的东西"——把问题改写成工具能解的形式，比硬啃底层结构划算。
这套思路不限于固件：改数据库 schema、往打包好的归档里加文件、给已发布的镜像补内容，都会遇到同一种"替换 vs 插入"的能力差别。先读用法，再决定是自己写还是绕路。