套件中心无法执行composer install，因其仅为图形界面且未提供CLI环境或预装Composer；必须通过SSH指定PHP路径（如/volume1/@appstore/PHP82/usr/bin/php）运行，或改用Docker容器方案。
为什么套件中心里根本没法敲 composer install
群晖套件中心不提供命令行入口，它只是图形化管理界面；你看到的“PHP”、“WebStation”等套件，只负责 Web 请求转发和 PHP-FPM 进程管理，**没有暴露 CLI 环境，也不预装 composer**。想在套件中心点几下就跑 composer install，这条路从底层就被堵死了。
必须用 SSH + 正确 PHP 路径才能执行
真正能运行 composer install 的地方只有 SSH 终端，但直接输 composer install 依然大概率失败——不是命令不存在，而是背后调用的 PHP 环境和 WebStation 不一致。
- 终端默认
php命令通常指向系统旧版（如 PHP 5.6），而你的站点绑的是 PHP 8.2 - WebStation 启用的扩展（
mbstring、openssl、phar）不会自动同步到 CLI 模式 -
phar.readonly = On在 CLI 的 php.ini 里常为默认值，导致composer.phar解包失败
所以每次运行都要显式指定路径：/volume1/@appstore/PHP82/usr/bin/php /usr/local/bin/composer install
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
常见报错直接对应修复动作
看到这些输出，别查文档，按顺序做三件事就行：
-
Could not open input file: composer→ 说明composer文件没放对位置，或软链失效；检查ls -l /usr/local/bin/composer是否指向真实文件 -
mbstring extension is missing→ 回 DSM → WebStation → PHP 8.2 → 扩展页勾选mbstring，再点「重启该 PHP 版本」 -
file_put_contents(.../autoload.php): Permission denied→ 八成是vendor/目录属主为root；执行sudo chown -R $USER:$USER vendor/ -
SSL certificate problem: unable to get local issuer certificate→ WebStation 的 PHP 未正确加载 CA 证书；用/volume1/@appstore/PHP82/usr/bin/php -r "print_r(openssl_get_cert_locations());"查cafile路径，再确认该文件存在且可读
更稳的方式其实是绕过 SSH 直接用 Docker
如果你发现反复调 PHP 路径、改 php.ini、修权限还是卡在某一步，说明 DSM 的 CLI 环境本身就不适合长期维护 Composer 项目。这时候别硬刚，换 Docker 是唯一被验证过的稳定路径：
- 拉镜像：
docker run --rm -v $(pwd):/app -w /app -u $(id -u):$(id -g) php:8.2-cli composer install - 关键点：不用装任何东西，不改任何配置，挂载当前目录，以当前用户 UID/GID 运行，
composer就在镜像里 ready-to-use - 注意别漏掉
-u $(id -u):$(id -g)，否则生成的vendor/属主会变成 root，下次 SSH 里就写不了
DSM 的 SSH 环境本质是“能用但不健壮”，Docker 容器才是它真正该跑 Composer 的地方——这点容易被忽略，直到你第 N 次删 vendor/ 重试。
