composer install 严格按 composer.lock 安装精确版本，确保环境一致；update 忽略 lock，重解 composer.json 依赖并更新 lock，仅用于明确升级场景。

Composer 不是包管理器，也不是 IDE 插件或运行时增强工具——它只做三件事：解析 composer.json 里的依赖约束、下载代码到 vendor/、生成可直接 require 的自动加载逻辑。

composer install 和 composer update 到底该用哪个

这直接决定你本地构建和线上部署是否一致。

• composer install 只读 composer.lock，严格安装其中记录的每个包的精确版本（含 commit hash 或 dist 校验和），适合 CI/CD、新同事拉代码后首次构建
• composer update 忽略 composer.lock，重新运行 SAT 求解器，按 composer.json 中的版本约束（如 "^2.0"）找最新兼容解——仅应在明确要升级依赖时执行
• 项目没有 composer.lock 时，install 会退化为 update 行为，结果不可复现；团队中必须把 composer.lock 提交进 Git

autoload 配置写错但不报错，类却找不到

这是最隐蔽的一类问题：错误不发生在命令执行时，而是在运行时抛出 Class 'YourNamespaceLogger' not found，但你反复确认路径、命名、文件都对。

Academic Composer Upload

辅助学术写作，包括查找资料、生成大纲、引用扩写及润色风格，同时确保引用规范。

下载

• psr-4 映射末尾必须带反斜杠："YourNamespace\": "src/"，少一个 就完全不匹配
• 路径是相对于 composer.json 所在目录的，不是相对于入口脚本或 vendor/
• 修改 autoload 后必须手动运行 composer dump-autoload，否则变更不会写入 vendor/autoload.php
• 若用 files 加载全局函数，路径必须真实存在且 PHP 进程有读取权限，否则 dump-autoload 会静默失败

为什么 vendor 目录不该提交，但 composer.lock 必须提交

vendor/ 是产物，composer.lock 是确定性快照——这是协作一致性的底层机制。

• vendor/ 体积大、含平台相关二进制（如某些扩展的 .so）、重复存储、易变，Git 存它纯属冗余
• composer.lock 记录每个包的精确版本、完整哈希、自动加载映射和完整依赖树结构，是上一次成功求解出的数学可行解
• 不提交 composer.lock = 放弃版本控制权，等于把“用哪个版本”交给每台机器的求解器随机决定
• 删掉 composer.lock 再跑 install，等同于裸跑 update，极大概率引入不兼容变更

真正容易被忽略的是：Composer 的核心不是下载，而是求解。所有 “could not be resolved” 错误，都不是网络或权限问题，而是 SAT 求解器已穷尽所有组合并证明无解——这时候翻日志、换镜像都没用，得回退约束或拆解冲突依赖。