关键不是还原旧权限，而是修复所有权和可执行位：vendor/bin脚本需chmod +x赋权（POSIX系统），vendor/等目录属主须为当前用户（用chown -R $(whoami)修复），shebang路径和UID一致性也需同步检查。
直接恢复被 composer install 意外修改的文件权限，关键不是“还原旧权限”，而是修复所有权和可执行位这两类最常出问题的点——因为 Composer 本身不记录或备份权限，它只按 ZIP 解压逻辑和系统默认 umask 创建文件。
为什么 vendor/bin 脚本突然不能执行了
现象是 vendor/bin/phpunit 显示有 x 位（ls -l 看是 -rwxr-xr-x），但运行仍报 No such file or directory。这不是权限没设好，而是 ZIP 解压后 shebang 行指向了错误 PHP 路径，或宿主机与容器 UID 不匹配导致内核拒绝加载解释器。
- 先确认 shebang 是否有效：
head -n1 vendor/bin/phpunit应为#!/usr/bin/env php - 再检查 CLI PHP 是否在 PATH 中：
which php；若无输出，说明环境里根本没装 CLI 版 PHP 或未加入 PATH - Docker 场景下，即使
ls -l看起来正常，也可能是 UID 1000 的文件被 UID 0 的容器进程读取失败——此时chmod完全无效，必须统一 UID 或改用非挂载方式初始化 vendor
vendor/ 或 composer.lock 归属变成 root 怎么办
这是 sudo composer install 留下的典型痕迹。系统不会“意外”改归属，一定是某次提权操作污染了目录树。修复不是靠回滚，而是主动归还控制权。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 定位问题路径：看报错里出现的完整路径，比如
file_put_contents(/path/to/vendor/autoload.php)→ 就修/path/to/vendor/ - 确认当前用户：
whoami，然后执行：sudo chown -R $(whoami):$(whoami) /path/to/vendor/ - 别只修 vendor/：如果
composer.lock也是root所有，一并加进去：sudo chown -R $(whoami):$(whoami) /path/to/vendor/ /path/to/composer.lock - 全局缓存也常被忽略：
sudo chown -R $(whoami):$(whoami) $(composer config --global cache-dir)
Linux/macOS 下如何让新装脚本自动带执行权
ZIP 包解压天然丢失 x 位，Git 也不跟踪，所以每次 composer install 都会重置。手动 chmod +x 只治标，加钩子才治本。
- 编辑项目根目录的
composer.json，在scripts块里加入：
"post-install-cmd": "chmod +x vendor/bin/*", "post-update-cmd": "chmod +x vendor/bin/*"
vendor/bin/* 不匹配隐藏文件（如 .phpunit），如有需要得单独列明chmod +x vendor/bin/phpunit vendor/bin/psalm
Windows 下 “不是内部或外部命令” 怎么办
这不是权限问题，是 Windows 根本不解析 #!/usr/bin/env php。chmod、PowerShell 的 Set-ExecutionPolicy 全部无效。
- 最稳方案：
php vendor/bin/phpunit显式调用，绕过 shell 查找机制 - 手动补
.bat包装器：在vendor/bin/下新建phpunit.bat，内容为：@php "%~dp0phpunit" %* - 换用自带
.bat的包：比如 Laravel 的artisan、Symfony 的console，它们发布时已内置包装器 - 别信“用 Git Bash 运行就能解决”——它只是模拟 POSIX 环境，一旦脚本被 Web 服务器或 CI 调用，照样失败
真正容易被忽略的是：权限问题往往不是孤立发生的。一次 sudo composer install 可能同时污染 vendor/、composer.lock、~/.composer/cache 甚至 opcache 写目录；而修复时只盯着报错那行路径，大概率漏掉上游依赖项。
