Node.js 发布依赖清单与许可证策略复核

先确定清单究竟属于哪一次发布

本流程适合准备发布 Node.js 项目的维护者，交付目标是可追溯的依赖与许可证复核证据，而不是一张笼统的“全部合规”证明。先固定确切的发布产物、源代码版本、package.json、锁文件和外部生成的 SBOM，记录生成器及设置、是否包含开发依赖，以及清单对应的构建标识，并为每份原件计算哈希。锁文件描述解析计划，打包、裁剪、可选依赖和平台条件都可能改变实际发布内容；不能把同一仓库中的文件自动视为同一次构建的证据。

私有包名、内部仓库地址等信息也可能敏感，上传前确认授权。不得把仓库令牌或访问凭证带入输入。需要脱敏时，保留受控原件与工作副本的映射，为副本另算哈希，避免拿副本哈希冒充原件。缺少构建关联时，应明确写出覆盖缺口。本页不会安装依赖、生成 SBOM、检验最终压缩包内容或执行漏洞扫描。

分清依赖声明、具体版本与结构正确

依赖审计器可检查 package.json 的声明问题，可选依赖树接受 npm package-lock.json 与 Yarn v1 yarn.lock。pnpm 或 Bun 的锁文件需要合适的外部读取器，不要仅为适应工具而转换原件并声称覆盖相同。没有可用锁文件时，只能说明声明层面的发现，不能补写已经验证的传递依赖。保留树的来源、深度限制与解析警告，尤其不能把解析错误后的空数组当作“项目没有依赖”。

例如 ^2.4.0 是声明范围，2.4.3 才是某次解析得到的具体版本。SemVer 校验用于后者；工作区引用、Git 引用和仓库标签要另记解析依据。JSON 结构校验需要自己提供与输入匹配、且校验器支持其方言的模式。结构通过不证明组件齐全，也不证明许可证字段真实。策略工具接受 SPDX 2.3 JSON、CycloneDX 1.5 JSON/XML；本流程中的 JSON 模式校验与 JSON 对比分支不适用于 XML，XML 需要另外保留原件并完成对应检查。

策略先定版，再解释变化与失败

运行前记录策略预设、copyleft 容忍设置、允许与拒绝列表，以及未知许可证处理方式。不能只记可能随版本改变含义的预设名称，要保存实际配置。策略审计后留存所选的 Markdown 或 SARIF 报告；需要两种格式时，用相同输入与设置分别运行。完整保存包含 AND、OR、WITH 等内容的许可证表达式，结合完整文本与义务寻求适当复核，不能截取其中较宽松的片段来代表整项依赖。

逐项检查失败组件、证据与可用依赖路径。缺失路径可能只是 SBOM 关系不全，不代表组件与项目无关。用 JSON 对比查看相对已批准版本的变化，再人工按组件身份、版本和完整表达式核对；数组顺序、生成标识与时间戳可能产生噪声，JSON 差异工具并非语义级包匹配器。新增、移除和无法解释的许可证变化都应有结论。例外须写清负责人、理由、适用发布、范围与到期时间，而不是静默扩充允许列表。

用可复核的交付包结束，而不是只留截图

单独维护 Markdown 台账，建议记录发布标识、产物与 SBOM 哈希、策略版本、组件标识、具体版本、完整表达式、依赖路径或其缺失、证据、处理决定与负责人。这些是人工复核建议字段，并非声称工具报告自动提供全部内容。尚无证据的项目应标为待处理或阻塞；输入或策略修正后重跑相关检查，并保留前后报告以便追溯。

Markdown 检查器只帮助改善可读性，不能判断许可证结论。PDF 是可选审阅副本，必须检查长标识、路径、表格和警告是否被裁切；排版无法完整呈现时，以完整源文件和原始报告为准。将机器可读报告、原件、台账与最终哈希保存到稳定归档中，不要把临时下载地址当作归档。SARIF 输出本身不会配置 CI 或自动产生失败门禁。Dockerfile 与环境问题转到相关容器发布流程，更广泛的文件对照使用差异流程；需要验证发布者身份而不只是字节相同时，再使用签名验证流程。