开发目录可以运行，打包部署却失败，常常是某些依赖只存在于本机。交付物应该由明确输入生成。
本文使用Java Web 小项目的演示工程与协作场景。初入团队时，重要的不只是写出功能，还包括让别人能够复现、审查和接手。本文使用匿名任务说明工作方法，不指代某家公司的内部流程或真实交付成绩。
1. 从现象推到机制
源码、依赖坐标、构建插件和资源文件共同决定产物。IDE 自动复制的 jar、未提交配置与本地绝对路径都会破坏可复现性。构建成功只证明生成产物，还需要核对部署包内的资源和运行配置。
图中的四个节点分别表示受控输入、构建过程、包内检查、部署验证。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
用 Maven 执行 clean package，检查 WAR 中的类、模板与依赖。环境差异通过外部配置注入，避免每次手工修改压缩包。
1
2
3
4
mvn clean package
jar tf target/demo.war
# 在独立测试容器中部署这一份产物
# 记录源码修订号与产物校验值
示例命令需要在独立演示工程中执行，路径和服务均由读者准备。操作前保留当前版本与输入，修改后对照原来的问题验证，而不是只证明新代码能够编译。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 删除本机生成目录再构建 | 必要资源仍应完整进入产物 |
| 只在 IDE 内成功 | 检查是否依赖工作区特有配置 |
| 部署包与验收包不同 | 验证结果不能直接沿用 |
对照 1：删除本机生成目录再构建
必要资源仍应完整进入产物。观察时记录构建输入是否全部受控。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：只在 IDE 内成功
检查是否依赖工作区特有配置。观察时记录命令行与 IDE 的构建差异。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：部署包与验收包不同
验证结果不能直接沿用。观察时记录两份产物的实际校验值。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
构建锁定不能保证所有外部服务永远可用。仍需保存依赖来源和升级策略，把可复现构建与长期维护分别管理。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“部署包与验收包不同”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
