别选“yes”配autoload，也别跳过name和author；package name必须为vendor/name格式（如acme/blog），否则报错；autoload需手动配置psr-4，路径用src/、命名空间双反斜杠；require填约束表达式（如^2.0），php版本须显式声明；type字段按项目类型设project或library，否则autoload失效。
直接说结论：别选“yes”来配 autoload，也别一路回车跳过 name 和 author——这两步填错，后续 class not found 或 composer validate 失败就是板上钉钉。
Package name 必须是 vendor/name 格式，否则卡死或报错
交互式运行 composer init 时，第一步就问 Package name。输入 myapp、MyApp、my-app! 或带空格的目录名（如 My Project），都会触发 Invalid package name 并卡住。
- 合法格式只有全小写、字母数字、连字符、下划线，且必须含
/，例如acme/blog、local/cli-tool - Git 用户名含中文或空格时，
composer init可能自动读取并拼出非法包名，建议显式传--name="myorg/myapp" - 漏 vendor 段（比如只写
myapp）会导致composer validate失败，CI 流水线中断
autoload 别信交互提示里的 “yes”
当它问 Would you like to define your autoload rules?，选 yes 后只支持 classmap，不支持你真正需要的 PSR-4。这不是疏忽，是长期存在的设计限制。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 如果你的类在
src/下、命名空间是App，必须手动编辑composer.json，加这段：
"autoload": {
"psr-4": {
"App\": "src/"
}
}
- 注意双反斜杠：
App\，不是App、App或App\\ - 路径必须是相对项目根目录的
src/，不能写成./src/、src或绝对路径 - 改完立刻跑
composer dump-autoload，composer install不会触发 autoload 重建
require 填的是约束表达式，不是版本号
交互中问到 Which version constraint to require for…，这里填错一个字符，composer install 就可能拉错包、装不上、或锁死版本。
-
^2.0：推荐日常使用，允许安装 2.x 全部兼容版本 -
dev-main：只适合本地开发调试，且需确认minimum-stability设为dev -
2.0.0（无符号）：锁定死版本，composer update不会升级 -
*或main：前者极可能引发冲突，后者直接报Could not find package - PHP 版本必须显式写进
require，如"php": "^8.1"；config.platform.php只影响解析，不约束依赖
type 字段设错，autoload 就白配
"type": "library" 和 "type": "project" 行为差异极大。设错不仅影响 autoload 加载逻辑，还可能导致包被错误引用、Flex 配方不生效，甚至线上环境 class not found。
- CLI 工具、网站、Laravel 应用 → 显式设
"type": "project" - 可被其他项目
require的通用组件 → 设"type": "library" - 没填
type字段，Composer 默认当library处理，对普通项目反而更危险 - 设错后，即使
composer dump-autoload成功，new AppHttpController()仍可能失败
最常被忽略的其实是路径和命名空间的对齐：src/App/Service/Logger.php 对应 namespace AppService，而不是 namespace App —— 这种错不会在 composer validate 里暴露，但运行时一定崩。
