Composer 不支持中文版本声明，仅识别语义化版本、分支别名或提交哈希；“中文统一声明”需通过 extra 字段自定义标识、私有 Packagist 映射虚拟标签、以及共用经审核的 composer.lock 实现。
Composer 的 composer.json 本身不支持“中文声明版本”
Composer 解析版本约束只认语义化版本（如 ^2.1.0）、分支别名（如 dev-main）或提交哈希，"version": "稳定版" 或 "版本": "v2.3.0" 这类中文字段会被完全忽略——它既不参与依赖解析，也不影响安装行为。所谓“中文实现统一声明”，实际是绕过 Composer 原生机制，在组织层做约定和工具链补充。
用 extra 字段承载中文语义标识，配合脚本校验
可在根项目或私有包的 composer.json 中，把中文含义写进 extra 区域，例如：
"extra": {
"release-phase": "预发布",
"service-tier": "核心服务"
}
这类字段不会被 Composer 处理，但可被自定义脚本读取。CI 流程中用 PHP 或 Shell 脚本检查所有依赖包的 composer.json 中 extra.release-phase 是否一致，不一致则报错中断构建。注意：extra 不传递继承，每个包需单独维护；且 Composer install 时不会校验它，必须显式调用校验逻辑。
通过私有 Packagist + 自定义 repositories 统一映射中文标签到真实版本
在公司内网部署 Satis 或 Private Packagist，为同一套代码打多个“虚拟标签”：比如把 v2.3.0 同时映射为 zh-stable、zh-legacy 等别名。然后在各服务的 composer.json 中这样写：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
"repositories": [
{
"type": "composer",
"url": "https://packagist.internal/"
}
],
"require": {
"vendor/common-lib": "zh-stable"
}
关键点在于：zh-stable 必须在私有仓库的 packages.json 里明确定义为指向某个真实版本（如 v2.3.0），否则 Composer 会报 Could not find package vendor/common-lib at version zh-stable。这种映射需人工或自动化同步更新，漏同步就会导致依赖解析失败。
真正起作用的是锁文件 composer.lock，不是中文描述
分布式系统里各服务最终行为一致，靠的是 composer.lock 固定所有依赖的精确版本和哈希值。哪怕你在 composer.json 里写 "version": "最新稳定"，只要 lock 文件存在且未被删改，composer install 就只会还原 lock 里的版本。所以统一版本管理的核心动作是：所有服务共用同一份经过审核的 composer.lock（或由中央 CI 生成后分发），而不是靠中文字段驱动。
容易被忽略的是：团队若习惯直接 composer update 而不走集中审批流程，再好的中文标签或私有映射都会失效——lock 文件一旦本地重生成，就脱离了统一控制。
