能，但仅对当前CLI命令生效，且PHP≥8.2已默认屏蔽该参数，执行时会忽略或报错；需确认实际加载的php.ini路径并修改其中phar.readonly=Off。
php -d phar.readonly=0 能临时绕过吗
能，但只对当前命令生效，且新版 PHP（≥8.2）已默认屏蔽该参数，执行时会直接忽略甚至报 Unknown option 错误。它不解决根本问题，还可能掩盖配置错位——比如你改了 Web 版 php.ini，却用 CLI 模式跑 composer，实际加载的是另一份配置。
常见误用场景：
- 在
composer install前加php -d phar.readonly=0 composer.phar install，看似成功，但后续composer update又失败 - 脚本里写死
php -d phar.readonly=0，CI 环境因 PHP 版本升级突然中断 - 以为加了参数就安全了，结果
phar.require_hash = 0被顺带打开，导致签名验证失效
怎么确认当前 CLI 模式真正生效的 php.ini
别猜路径，直接问 PHP：
php --ini 输出类似：Configuration File (php.ini) Path: /etc/php/8.2/cliLoaded Configuration File: /etc/php/8.2/cli/php.ini
重点看 Loaded Configuration File 行。如果显示 (none)，说明没加载任何 ini 文件，phar.readonly 就维持默认 On；如果路径指向 Apache 或 FPM 的配置（如 /etc/php/8.2/apache2/php.ini），那 CLI 根本没读它。
验证是否生效的最小检查：
php -r "echo ini_get('phar.readonly') ? 'On' : 'Off';" —— 必须输出 Off
修改 php.ini 的正确写法和位置
phar.readonly 是 INI 指令，不是扩展名，不能写成 extension=phar.readonly；也不能塞进 [phar] 小节里——PHP 不认这种分组写法。
必须放在全局配置段（即文件顶部无方括号包裹的位置），例如：
; 开启 phar 写入支持（仅限开发/CI 环境） phar.readonly = Off phar.require_hash = On
注意两件事：
-
phar.require_hash = On应保持开启，否则未签名的 PHAR 可被加载，构成安全风险 - 改完后不需要重启 nginx/Apache，但必须新开终端或重新运行
php命令，因为 CLI 进程是单次加载配置
Windows 下 %APPDATA%\Composer 目录权限错乱怎么办
“以管理员身份运行” PowerShell/CMD 是最大诱因：它会让 Composer 在 C:\Windows\System32\config\systemprofile\AppData\Roaming\Composer 创建目录，而你的普通账户根本没权限访问该路径，导致 composer global require 看似成功，实则二进制文件丢了。
立刻执行：
- 关闭所有以管理员身份启动的终端
- 重命名或删除
%APPDATA%\Composer（先备份） - 用普通用户权限运行一次
composer --version，让它重建干净目录 - 检查
composer config --global bin-dir输出是否在用户可写路径下（如%USERPROFILE%\AppData\Roaming\Composer\vendor\bin）
真正的坑不在 phar.readonly 设置本身，而在于你改对了哪一份配置、又用哪个用户身份去触发它——CLI 和 Web 的配置分离、Windows 用户目录所有权错位，这两点比参数开关更常导致失败。
