composer 不提供代码依赖指纹匹配能力，其 lock 文件仅为确定性快照而非指纹；真正溯源需在下载后、git 克隆后及 autoload 加载时注入校验逻辑，绑定字节级内容并确保采集时机足够晚。

Composer 本身不提供“代码依赖指纹匹配”能力，也没有内置的供应链安全风险溯源模型。所谓“基于代码依赖指纹匹配实现溯源”，是第三方安全工具（如 Snyk、Psalm、PHPStan 插件或自研扫描器）在 Composer 生态上构建的增强能力，不是 composer install 或 composer update 的默认行为。

Composer 的 lock 文件不是指纹，而是确定性快照

composer.lock 记录的是每个包的精确版本、源类型（dist/git）、dist 的 sha256（仅限 dist 包），以及依赖树结构。它保证重装一致性，但不覆盖以下场景：

• 同一 commit 的不同构建产物（如 build 脚本注入、环境变量污染）会产生不同二进制哈希，但 composer.lock 仍认为“相同”
• git 包只记录 reference（commit hash），不校验工作区实际检出内容是否被篡改（比如 .git 目录被替换）
• 未启用 "secure-http": true 时，HTTP 源可能被中间人劫持，导致下载内容与预期不符

想做指纹级溯源？必须介入安装/加载链路

真正实现“代码级指纹匹配”，需要在以下环节注入校验逻辑：

Composer

Composer 是 PHP 生态常用依赖管理工具，用于安装框架、组件和项目依赖。

下载

• 下载后、解压前：对 dist 包的 sha256 做二次核验（可 hook Composer\Downloader\ZipDownloader::download()）
• git 克隆后：运行 git verify-commit 或比对 git archive --format=tar HEAD | sha256sum 与预期指纹
• autoload 加载时：用 opcache_get_status()['scripts'] 或 filemtime() + hash_file('xxh128', $file) 对已加载 PHP 文件做运行时指纹采集
• 避免直接信任 vendor/autoload.php —— 它不校验文件完整性，只按路径 require

常见误用：把 version 字符串当指纹

很多团队用 composer show --direct --format=json 提取版本号做“依赖画像”，但这完全不可靠：

• v2.0.0 可能对应 3 个不同 commit（tag 被 force push、镜像同步延迟）
• dev-main 这类分支名无固定指向，每次 composer update 都可能拉到新代码
• 私有包若用 path 类型，composer show 显示的仍是本地路径，无法反映真实代码状态
• 别拿 composer.json 里的 require 版本约束（如 ^1.2）当指纹——它只是范围，不是确定值

真正的指纹必须绑定到具体字节内容，且采集时机要足够晚（最好在文件写入磁盘后、首次 require 前）。多数团队卡在“不知道该在哪一环埋钩子”，而不是缺算法或工具链。