不能用“中文”做 composer 包名或命名空间，因为 composer 的 name 字段仅允许小写字母、数字、连字符和正斜杠，命名空间须符合 php 规范（字母/数字/下划线），含中文会直接触发 invalid package name 错误、parseerror 或 class not found；路径、仓库 url 含中文亦会导致 realpath 失效、symlink 创建失败及 git 乱码，实操必须统一使用英文标识，中文语义通过注释和文档表达。
不能用“中文”做 Composer 包名或命名空间，所谓“中文实现”是误解——Composer 依赖解析、PSR-4 自动加载、文件系统路径全部基于 ASCII 字符，中文会直接导致 Class not found、autoload.php 加载失败、Git 路径乱码等硬性错误。
为什么包名/命名空间不能含中文
Composer 的 name 字段（如 "myapp/auth-component"）必须符合 Composer 官方命名规范：仅允许小写字母、数字、连字符（-）和正斜杠（/），且必须以字母开头。命名空间（如 MyApp\Auth）需满足 PHP 语言规范：只能是字母、数字、下划线，且不能以数字开头。
常见错误现象：
- 在
composer.json中写"name": "我的组件"→ 执行composer install直接报错：Invalid package name "我的组件" - 命名空间写成
我的公司\支付→ PHP 解析失败，use 我的公司\支付\Alipay;触发ParseError: syntax error - 路径含中文（如
./components/用户中心）→ Linux/macOS 下 symlink 创建失败；Windows 下 Git 提交后路径损坏，CI 构建时url找不到目录
path 仓库配置中 url 路径能否用中文
不能。虽然文件系统可能支持中文路径，但 Composer 的 path 类型仓库要求 url 是**可被所有环境一致解析的相对路径**，且内部使用 realpath() 和 dirname() 处理，一旦含中文，realpath() 在不同 locale 下行为不一致，导致 symlink 指向错误或静默失败。
实操建议：
- 本地开发目录统一用英文命名，如
./components/auth、./shared/logging - 团队协作前约定命名规则，避免
user-center和user_center混用 - 若历史项目已存在中文路径，先重命名为英文（如
用户中心 → user-center），再更新所有repositories.url值
如何让中文业务语义体现在组件设计中
语义表达应在代码层，而非包标识层。命名空间、类名、方法名可用英文准确表达中文业务概念，这是行业通用实践。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
例如：
- 业务域“订单中心” → 命名空间
MyApp\Order，类名OrderService、OrderRepository - 功能“实名认证” → 方法名
verifyRealName()，DTO 属性$idCardNumber、$realName - 配置键用英文但注释写中文：
'payment.alipay.timeout' => 30 // 支付宝超时秒数
这样既保证 Composer 和 PHP 运行时稳定，又不影响团队理解业务含义。
Windows 下 symlink 创建失败的典型原因
即使路径全是英文，Windows 仍常因权限或系统设置导致 composer update 后 vendor 中未生成 symlink，而是复制了一份代码。
检查与修复步骤：
- 确认终端以管理员身份运行（PowerShell 或 CMD）
- 启用开发者模式：Win10/11 设置 → 更新与安全 → 开发者选项 → 开启“开发者模式”
- 检查 Git Bash 是否启用 Windows Symlinks：运行
git config --global core.symlinks true - 验证是否生效：
ls -la vendor/myapp/auth-component输出应含-> ../components/auth - 若仍失败，临时改用
"options": {"symlink": false}+post-update-cmd脚本手动链接（仅作备用）
真正稳定的跨项目复用，不靠路径“看起来像中文”，而靠包结构清晰、命名空间收敛、autoload 精准——这些都必须建立在合法 ASCII 标识之上。任何试图绕过这一层的“中文方案”，最终都会在 CI、Docker 或多用户环境中暴露问题。
