composer 不支持中文元数据，包名强制 ascii；技术债雷达图需从 composer.json、composer.lock 和静态分析工具提取量化指标，统一归一化后映射到5个核心维度。
Composer 中文元数据不存在，别被名字骗了
Composer 本身不支持“中文元数据”——composer.json 是 JSON 格式，键名必须是合法 ASCII 字符串，name、description、keywords 等字段虽可填中文值，但包名（如 vendor/name）强制要求小写字母、数字、连字符和下划线，不允许中文。所谓“基于 Composer 中文元数据”是个常见误解，实际想表达的通常是：用中文描述的包信息 + 自定义字段 + 静态分析生成技术债视图。
真正能落地的技术债雷达图生成路径
核心不是解析中文，而是从 composer.json 和代码仓库中提取可量化指标，再映射到雷达图维度。常见有效维度包括：phpstan-level、psalm-level、deprecated-count、unused-dependencies、outdated-minor-patches、license-risk（如含 GPL 的依赖）。这些都得靠工具链拼装，不是 Composer 自带能力。
- 用
composer show --direct --outdated提取过期依赖，过滤出minor和patch级别更新 - 用
phpstan analyse -c phpstan.neon --no-progress输出 JSON 报告，统计 error/warning 数量并按严重性加权 - 用
composer depends --tree vendor/package辅助识别废弃但被强依赖的包 - 自定义
extra字段（如"extra": {"tech-debt": {"test-coverage": 72.5}}）可人工录入不可自动采集的指标，但需配套校验脚本防止误填
雷达图渲染时最容易翻车的三个点
雷达图不是美化装饰，数值失真会直接误导决策。关键陷阱在归一化和维度权重：
- 不同指标量纲差异极大：比如
outdated-count是整数（0–50），而test-coverage是百分比（0–100），直接喂给 Chart.js 会压扁前者。必须统一缩放到 [0,1] 区间，且建议用分位数截断（例如 >95% 分位的outdated-count视为 1） -
composer.json里的license字段常为"MIT"或"proprietary"，但风险判断不能只看字符串匹配——要查 SPDX License List，比如"GPL-2.0-only"和"GPL-2.0-or-later"风险等级不同 - 雷达图每个轴代表一个维度，但人眼对 >6 个轴极度不敏感。强行塞进
coding-standard-violations、php-version-mismatch、autoload-duplicates等 8 项，结果就是谁也看不出问题在哪。建议固定 5 轴：依赖健康度、静态分析质量、测试覆盖、PHP 兼容性、许可证合规性
别漏掉 composer.lock 里的隐藏线索
composer.lock 比 composer.json 更真实——它记录了实际安装的版本、哈希、平台配置。技术债常藏在这里：
- 检查
packages数组里每个包的dist.reference是否指向dev-或master分支（即用了不稳定版本），这类包应单独标记为高风险 - 对比
platform字段（如"php": "8.1.0"）和项目实际运行环境，若线上是 PHP 8.2 而 lock 文件锁死在 8.1，说明存在隐性兼容风险 -
packages-dev里出现生产环境不该存在的工具（如phpunit/phpunit被写进require而非require-dev），属于依赖污染，需计入“依赖健康度”扣分项
雷达图本身不难画，难的是让每个轴的数值经得起推敲。中文描述只是表象，真正要盯住的是 lock 文件的 reference、neon 配置里的 baseline、以及你敢不敢把 composer outdated --direct 的结果当真。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
