Composer 配置关键在 autoload 与 require 的联动匹配：psr-4 键须以 \ 结尾、值为相对路径且目录结构需严格对应命名空间；require 为运行时必需依赖，require-dev 仅用于开发；composer.lock 记录精确依赖快照，不可删改，升级用 composer update vendor/package。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
Composer 配置不是写完 composer.json 就能跑通的，关键在 autoload 和 require 的联动方式是否匹配你的目录结构和命名习惯。
composer.json 里 autoload 怎么配才不报 Class not found
常见错误是照抄别人配置却忽略自己的文件路径和命名空间。比如你写了 "App\": "src/App/"，但实际类文件放在 src/app/（小写），Linux 下直接失败；又或者类声明是 namespace AppControllers;，但 autoload 只映射了 App\ 根命名空间，没覆盖子命名空间——Composer 不会自动递归匹配。
- 用
psr-4时，键必须以\结尾（如"App\"），值必须是相对项目根的物理路径（如"src/"），且该路径下要存在对应命名空间层级的子目录 - 如果类文件没按 PSR-4 规则组织（比如把
AppControllersHome放在src/Home.php），就得改用classmap或files - 改完
autoload后必须运行composer dump-autoload，否则新规则不生效
require 和 require-dev 混着写会出什么问题
最直接的影响是：CI 环境执行 composer install --no-dev 时，require-dev 里的包全被跳过，如果你的测试工具（比如 phpunit）被误写进 require，它会打进生产镜像，增大体积还可能引入安全风险；反过来，如果某个运行时依赖（比如 monolog/monolog）被错放进了 require-dev，本地开发正常，部署后直接 Class not found。
- 判断标准很简单：这个包是不是代码执行时「必须加载」的？是 → 进
require；只用于测试、生成文档、静态分析 → 进require-dev -
composer install默认只装require，加--dev才装require-dev；而composer update默认两者都更新 - 线上部署应固定使用
composer install --no-dev --optimize-autoloader
为什么 composer.lock 不能删，也不能手改
它不是缓存，而是精确记录了每个包的 commit hash、下载地址、依赖树快照。删了再 composer install，哪怕 composer.json 没变，也可能拉到新版的间接依赖（比如 guzzlehttp/psr7 从 1.x 升到 2.x），导致行为突变；手改更危险：composer install 会校验 lock 文件签名，内容篡改后直接报错 The lock file does not contain require-dev information 或更隐蔽的哈希不匹配。
立即学习“PHP免费学习笔记（深入）”；
- 协作中必须提交
composer.lock到 Git，尤其 PHP 项目对依赖版本敏感 - 想升级某个包？用
composer update vendor/package，别碰 lock 文件本身 - 如果 lock 文件损坏（比如合并冲突没处理干净），删掉它再
composer install是唯一安全做法
真正卡住人的往往不是语法，而是 autoload 路径和命名空间之间那层薄薄的映射关系——差一个斜杠、少一个反斜杠、大小写不一致，在 Windows 上可能不报错，到了容器里就挂掉。
