Composer audit不支持中文包名或元数据，因它仅比对composer.lock中英文vendor/name格式包名与FriendsOfPHP安全数据库的CVE条目，该库无中文字段、无映射表，私有/中文命名包默认被跳过。
不能直接构建——Composer audit 本身不支持中文元数据，也不解析任何非 Packagist 官方命名空间的包信息。 它只比对 composer.lock 中记录的精确包名（如 guzzlehttp/guzzle）与 FriendsOfPHP/security-advisories 数据库里的英文 CVE 条目。所谓“中文元数据”在 Composer 安全扫描链路中根本不存在、不被读取、也不参与匹配。
为什么 composer audit 不认中文包名或中文描述
Composer 的 audit 命令底层只做两件事：提取 composer.lock 里 name 字段的值（强制为 vendor/name 格式，全部小写、ASCII）、然后查 FriendsOfPHP 的 JSON 数据库。该数据库所有条目均以英文包名 + 英文 CVE 描述存储，无本地化字段，也无中文映射表。
- 你在
composer.json里写"name": "我的公司/支付sdk"→audit直接跳过，不报错也不扫描 - 私有仓库返回的包信息含中文
description或keywords→audit完全忽略这些字段 - 用
repositories指向一个带中文 README 的 Git 仓库 → 扫描时仍只看name是否在 FriendsOfPHP 库中存在
想扫私有/中文命名包？你得绕开 audit 自己搭
如果目标是覆盖内部用中文命名的 SDK、组件或 fork 包，audit 不是入口，而是终点——你得先让这些包“变成可比对的”。可行路径只有两条：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 在
composer.json中为每个私有包显式声明"type": "package"，并手动填充"advisories"字段，格式严格对齐 Symfony 安全通告结构（含cve、title、versions等），否则audit仍无视 - 放弃
audit，改用composer show --format=json --locked提取所有已安装包的name和version，再调用外部漏洞 API（如 OSV.dev）做语义化查询：例如把mycorp/payment-sdk映射成github.com/mycorp/payment-sdk，再查其 GitHub Security Advisories
CI 中误以为“扫了中文包”其实是假阳性
常见错误是把 composer install 输出里的中文提示（如“正在安装 xxx”）当成扫描结果，或看到 composer audit --no-interaction 成功退出就认为全覆盖。实际上：
-
audit默认不扫require-dev，但你内部测试工具链可能用中文命名，且含反序列化漏洞 -
--all参数只扩展 transitive dependencies，不扩展私有命名空间；它不会把acme/log当作monolog/monolog的别名去查 - 加了
--format=json后若输出{"advisories":[],"packages":[]}，大概率不是“安全”，而是“没匹配到任何包”
真正卡点不在代码怎么写，而在你是否清楚：FriendsOfPHP 数据库不收中文条目，Composer 不解析中文字段，audit 的设计哲学就是“精确匹配、零翻译、强约定”。想扫中文元数据，就得自己建映射层、补数据源、写校验逻辑——这不是配置问题，是架构选择。
