升级主版本时composer.json和composer.lock必须可写，否则会中断流程；需用chmod u+w或chown修正权限，禁用sudo运行及手动覆盖，Docker/CI中须显式启用读写。
升级主版本时 composer.json 和 composer.lock 的写入权限问题
Composer 升级主版本（如 Laravel 9 → 11）本身不修改系统配置文件，但会强制重写 composer.json 和 composer.lock —— 这两个文件若被设为只读、归属错误或位于受限路径（如 Docker 容器的 /usr/bin 或 CI/CD 的临时挂载目录），就会直接中断整个流程。
-
composer.json必须可写：执行composer require laravel/framework:^11.0 --with-all-dependencies会先尝试改写该文件中的版本约束；若失败，报错类似Could not write to composer.json -
composer.lock同样必须可写：即使你跳过require直接改composer.json后跑composer update，Composer 仍需生成新 lock 文件；只读 lock 文件会导致Failed to write lock file并退出 - 常见陷阱是误将项目根目录整体设为
chmod 555或在 GitHub Actions 中用actions/checkout@v4默认启用read-only: true，此时必须显式加read-only: false
Linux/macOS 下权限不足的快速修复方式
不是所有环境都允许 sudo，也不是所有用户都清楚 composer.json 所在目录的实际属主。最稳妥的做法是先确认再修正：
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 运行
ls -l composer.json查看当前权限和所属用户/组；若显示-r--r--r--或属主不是当前用户，就需调整 - 仅放开必要文件：执行
chmod u+w composer.json composer.lock（不建议chmod 777） - 若属主错误（如属 root），且你在 Docker 或 CI 中无权切用户，改用
chown $USER:$USER composer.json composer.lock；CI 环境中可加run: chown $(id -u):$(id -g) composer.json composer.lock - Windows 用户注意：Git Bash 下可能因 Windows ACL 导致“Permission denied”，此时应右键文件属性 → “安全”选项卡 → 编辑当前用户权限 → 勾选“写入”
Docker 和 CI/CD 中的典型只读场景与绕过方案
很多团队在容器化部署或自动化流水线里默认禁用写权限，结果 composer update 在构建阶段静默失败或报错，却没意识到是权限问题。
- Docker 构建时，
COPY . /app后文件常继承构建机的只读属性；应在RUN阶段立即修复：RUN chmod u+w /app/composer.json /app/composer.lock - GitHub Actions 中，
actions/checkout默认挂载为只读；必须显式声明：with: { read-only: false }，否则后续composer require必然失败 - GitLab CI 中，
cache恢复的composer.lock可能带immutable属性；可在before_script加chmod u+w composer.lock - 绝对不要用
--ignore-platform-reqs掩盖权限问题：它跳过 PHP 版本等检查，但不解决文件不可写，反而让错误更隐蔽
为什么不能靠备份后手动覆盖？
有人想绕开权限问题：先 cp composer.json composer.json.bak，再本地改好再 cp 回去。这在单人开发可行，但在协作环境中极危险。
- 手动覆盖会丢失其他协作者已提交但你未拉取的
composer.json修改（比如新增了 dev 依赖） -
composer.lock是二进制哈希树，不能 diff 合并；直接覆盖会导致依赖解析状态与实际代码不一致，CI 构建可能通过，但运行时报Class not found - Composer 在写 lock 文件前会校验
composer.json的完整性；若你本地改的 JSON 格式有空格或逗号错误，composer update会直接拒绝写入，而非静默忽略
No lock file found. Updating dependencies instead. 或 Generating autoload files 后无响应——因为 Composer 尝试写 lock 失败后降级为全量重算，耗时暴涨甚至 OOM。遇到这类现象，第一反应不该是调大内存，而是 ls -l 看文件权限。 
