Composer项目出问题八成因composer.json配置或目录结构未对齐：命名空间结尾缺反斜杠、autoload路径错误、composer.lock未提交。
Composer 项目出问题，八成不是代码写错了，而是 composer.json 配置或目录结构没对齐——类找不到、Class not found、composer install 后 vendor 里空空如也，往往就卡在这三处：命名空间结尾缺反斜杠、autoload 路径写错、composer.lock 没提交。
PSR-4 命名空间必须以反斜杠结尾
Composer 解析 "MyPackage": "src/" 是靠字符串前缀匹配的。不加反斜杠，"MyPackage": "src/" 在 JSON 中就是纯字符串，匹配 MyPackageHttpClient 时会截掉 MyPackage，剩下 HttpClient，然后去拼 src/Http/Client.php——但你的类实际在 src/Http/Client.php，路径对不上。
更隐蔽的是，MyPackageFoo 也会被错误匹配进来，而它根本不是你包里的类。
-
"MyPackage": "src/"✅ 正确：只匹配以MyPackage开头的命名空间 -
"MyPackage": "src/"❌ 错误：JSON 解析后无转义，匹配逻辑失效 -
"MyPackage\": "src/"❌ Windows 下易多打一个反斜杠，PHP 字符串解析出错
autoload 和文件系统路径必须三者对齐
PSR-4 不是“写对了就行”，而是命名空间声明、composer.json 里的映射、文件物理路径三者必须严丝合缝。常见错误是改了目录名但忘了同步改 composer.json，或者类文件里写的 namespace 和映射前缀不一致。
例如：类文件在 src/Http/Controllers/HomeController.php，里面写的是 namespace AppHttpControllers;，那 composer.json 就得配：
"autoload": {
"psr-4": {
"App\": "src/"
}
}
-
src/下不能混放不同命名空间的类，否则自动加载器可能误加载或找不到 - 改完
autoload后必须手动执行composer dump-autoload -o，否则变更不生效 - 生产环境用
-o（optimize-autoloader），但上线前要确认没漏掉反射类等动态注册场景
require 和 require-dev 必须按运行时依赖划分
不是“本地开发用”和“线上不用”的区别，而是“PHP 执行业务逻辑时是否 new 或 use 它”。分错会导致 CI 报错、线上挂掉、vendor 体积异常。
- 打开所有
src/和app/下的 PHP 文件，全局搜索use和new，凡出现的第三方类，其包必须在require里 - 只在
tests/、bin/或 GitHub Actions 脚本里出现的工具（如phpunit/phpunit、phpstan/phpstan），必须进require-dev - 验证方法：
composer install --no-dev && php -r "new AppHttpControllersHomeController();"能成功实例化，才说明运行时依赖完整
composer.lock 必须提交，vendor 必须忽略
composer.lock 是环境一致性的唯一事实来源。不提交它，等于放弃对依赖版本的控制；提交 vendor/，等于把构建产物当源码管，只会制造冲突、增大仓库体积、误导新成员。
-
.gitignore中必须包含：/vendor/和!/composer.lock - CI/CD 流水线中必须用
composer install --no-dev --optimize-autoloader，而不是composer update - 团队所有成员必须运行
composer install（而非update），确保安装的是 lock 文件中锁定的版本
最常被忽略的一点：包开发者自己不跑 composer install，但必须保证 composer.json 里 autoload 和 autoload-dev 严格隔离——否则用户 install --no-dev 后，测试类仍可能被加载，引发 Fatal error: Class 'PHPUnitFrameworkTestCase' not found。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
