composer不支持中文元数据，所有中文字段需人工维护并由下游工具解析展示；包名必须符合英文规范，description等字段需utf-8无bom编码、截断防ui溢出、转义防xss，前端展示须处理字体fallback与安全截取。
Composer 中文元数据不是官方支持的功能
Composer 本身不解析或渲染中文字段，name、description、keywords 等字段只是纯文本，无论中英文都照存照读。所谓“中文元数据”，实际是人为在 composer.json 里填入中文值，再由下游工具（如看板系统）自行读取并展示——这意味着你得自己控制数据来源和渲染逻辑，不能指望 Composer 自动做本地化或语义处理。
- 所有中文字段必须手动维护，CI 流程里无法自动校验语法或长度
-
description超过 200 字会破坏某些旧版看板的 UI 布局，建议截断到 120 字以内 - 包名（
name）仍需遵守 Composer 规范：只能含小写字母、数字、连字符和斜杠，不可用中文
从 composer.lock 提取中文元数据要绕过 vendor 目录
直接读 vendor/composer/installed.json 不可靠：它只包含已安装包的运行时信息，且不含原始 composer.json 中的中文 description（Composer 会把该字段丢给插件或外部服务处理）。真正可用的源头是每个包根目录下的 composer.json 文件，但企业私有包往往通过 Satis 或 Private Packagist 托管，需走 HTTP API 或 Git 克隆后解析。
- 推荐方式：用
git clone --depth 1拉取每个包的最新 tag，再读其composer.json——避免依赖本地vendor状态 - 若用 Satis，可调用其
/packages.json接口，但注意该接口默认不返回description的原始值，需在 Satis 配置中显式启用"archive": {"format": "zip"}并确保源码中保留中文字段 - 遇到
json_decode()报JSON_ERROR_UTF8？说明文件用了 GBK 编码，必须先用mb_convert_encoding($content, 'UTF-8', 'GBK')转码
PHP 看板后端解析中文字段时的编码与缓存陷阱
PHP 默认用 default_charset = "UTF-8"，但 file_get_contents() 读取文件时不自动识别 BOM，而部分 Windows 编辑器保存的 composer.json 带 UTF-8 BOM，会导致 json_decode() 返回 null 且无报错。
- 安全做法：读取前用
mb_substr($content, 0, 3) === "\xEF\xBB\xBF"检查并剔除 BOM - 中文字段常含 HTML 实体（如
&），但 Composer 不转义，看板前端直接echo会 XSS，务必用htmlspecialchars($desc, ENT_QUOTES, 'UTF-8') - 别把整个
composer.json内容缓存进 APCu 或 Redis，字段变动频繁，应只缓存提取后的结构化数组（如['name' => 'xxx', 'zh_desc' => 'yyy']），TTL 设为 1 小时足够
前端展示中文包名需处理字体与省略策略
浏览器对中文字体 fallback 不统一，尤其在 Linux 服务器生成的 PDF 或截图看板中，SimSun、Noto Sans CJK SC、Source Han Sans CN 优先级一错就显示方块。同时，包名+中文描述组合长度远超英文，CSS 截断逻辑必须适配。
- CSS 中强制指定字体栈：
font-family: "Noto Sans CJK SC", "Source Han Sans CN", sans-serif;，避免依赖系统默认 - 用
text-overflow: ellipsis时，必须搭配white-space: nowrap和固定宽度；对多行中文描述，改用-webkit-line-clamp: 2+display: -webkit-box - 不要用 JavaScript 的
str.substring(0, 30)截中文——一个汉字占 3 字节，可能切在 UTF-8 中间导致乱码，改用mb_substr($str, 0, 30, 'UTF-8')
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
