composer init不配置autoload，命名空间冲突由手动编写的PSR-4前缀决定；防冲突关键在于使用带组织和服务标识的唯一前缀（如"MyOrgUserService": "src/"），避免"App": "src/"等宽泛映射。
composer init 本身不支持配置自动加载前缀，它只生成基础 composer.json 框架；真正决定命名空间是否冲突的，是后续手动写的 autoload 配置，不是 init 过程。
为什么 composer init 不能防微服务包冲突
执行 composer init 时，它会问你包名、描述、作者等元信息，但完全跳过 autoload 字段。哪怕你输入 myorg/app-service 作为包名，它也不会自动帮你写 "App\": "src/" 或更安全的 "MyOrg\AppService\": "src/"。所有 PSR-4 前缀都得你手写进 composer.json，否则默认没有自动加载规则——也就谈不上“防冲突”。
- init 生成的
composer.json中autoload字段压根不存在，不是空对象，是彻底缺失 - 微服务场景下多个包共用
App或Common这类宽泛前缀，恰恰是冲突高发点，而 init 不做任何提醒或校验 - 如果你依赖的第三方包（比如某个内部 SDK）自己用了
"": "src/"，init 更不可能发现或干预
微服务项目该配什么 PSR-4 前缀才不容易撞车
核心原则：前缀必须带组织/产品标识，且以反斜杠结尾。别图省事写 "App": "src/"，这等于给所有微服务开一扇共用大门。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 推荐格式：
"MyOrg\UserService\": "src/"、"MyOrg\PaymentGateway\": "src/"—— 组织名 + 服务名 + 反斜杠，三者缺一不可 - 绝对避免：
"App": "src/"（太泛）、"App": "src/"（少反斜杠，PSR-4 解析失效）、"": "src/"（全局映射，必撞） - 如果服务已上线且命名空间难改，可用
exclude-from-classmap在你项目里屏蔽冲突文件，但仅对 classmap 有效，对 PSR-4 无效
验证前缀是否真生效的三个动作
写了前缀不等于它被 Composer 识别。很多微服务部署失败，卡在 autoload 没注册成功这一步。
- 运行
composer dump-autoload -v，看输出里有没有你声明的前缀和对应路径（例如MyOrgUserService => src/） - 检查
vendor/composer/autoload_psr4.php，搜索你的命名空间关键词，确认只出现一次且路径正确 - 在任意脚本里加
var_dump(class_exists('MyOrg\UserService\UserRepository'));，返回false就说明 autoload 根本没走通，不是类不存在，而是前缀没注册
APCu 缓存前缀要跟 PSR-4 前缀对齐吗
不需要对齐，但必须隔离。APCu 前缀解决的是多项目缓存键冲突，PSR-4 前缀解决的是类定义冲突，两者维度不同。
- APCu 前缀建议按环境+服务命名，比如
myorg-userservice-prod，用composer dump-autoload --optimize --apcu-autoloader --apcu-autoloader-prefix=myorg-userservice-prod - 这个前缀和 PSR-4 里的
MyOrg\UserService\没有映射关系，但若所有微服务都用同一个 APCu 前缀（比如全用app），缓存会互相覆盖，导致类加载行为随机变化 - APCu 前缀不写进
composer.json，它是命令行参数，必须集成到 CI/CD 部署脚本中固化
最麻烦的不是写错前缀，而是团队里有人在本地改了 composer.json 却没跑 dump-autoload，或者 Docker 构建时漏掉这步，结果线上跑的是旧 autoload 文件——这种问题在线上查半天，最后发现只是少敲了一条命令。
