必须用WebStation绑定的PHP路径安装和运行composer，否则因环境错配导致mbstring缺失、Phar失败、autoload空白等错误；需核对php -v和php -m路径，启用对应扩展，修改CLI的php.ini确保phar.readonly=Off及扩展加载一致。
composer 在群晖 NAS 上不能“直接装”，必须和 WebStation 实际运行的 PHP 版本严格对齐，否则后续 composer install 会报 mbstring 缺失、Phar 解包失败、autoload 加载空白等错误——这不是权限问题，是环境错配。
确认 WebStation 真正用的 PHP 路径和扩展
WebStation 可能启用了 PHP 8.1、8.2 多个版本，但每个站点只绑定其中一个；而终端里默认的 php 命令往往指向系统旧版（比如 PHP 5.6），完全不兼容。
- 进 DSM → WebStation → PHP 设置 → 找到你站点绑定的版本（如 PHP 8.2），记下它的
PHP Path（典型路径：/volume1/@appstore/PHP82/usr/bin/php） - SSH 登录后，用这个完整路径验证：
/volume1/@appstore/PHP82/usr/bin/php -v，确保版本匹配 - 再检查关键扩展是否启用：
/volume1/@appstore/PHP82/usr/bin/php -m | grep -E "(phar|zlib|json|mbstring|openssl|curl)" - 缺哪个，就回 WebStation → 对应 PHP 版本的「扩展」页勾选，然后「重启该 PHP 版本」（不是重启整个 WebStation）
别用 curl | php，改用 PHP 内置 copy() 下载安装器
群晖默认没 curl，或版本太老不支持 HTTPS SNI；且 php 不加路径会调用错版本，导致生成的 composer.phar 和 WebStation 运行时环境不一致。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先确保有可用的
curl：套件中心添加 SynoCommunity 源，安装curl（路径通常是/opt/bin/curl） - 用 WebStation 的 PHP 路径执行下载和安装：
/volume1/@appstore/PHP82/usr/bin/php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"/volume1/@appstore/PHP82/usr/bin/php composer-setup.php --filename=composer --install-dir=/usr/local/bin --version=2.7.7rm composer-setup.php - 注意：不要用
sudo -i切 root 后建软链——/usr/local/bin是只读挂载点，但允许普通 DSM 用户（如admin）创建符号链接
验证 composer 是否真能跑通 Laravel/Lumen/Cloudreve 类项目
装完 composer 只是第一步；真正容易翻车的是项目首次 composer install —— 它会触发 autoloader 生成、插件加载、脚本执行，对 CLI 环境要求比 Web 更严。
- 在项目目录下运行：
/volume1/@appstore/PHP82/usr/bin/php /usr/local/bin/composer install（显式指定 PHP 路径） - 若报
mbstring或xml扩展缺失，说明 CLI 的php.ini和 WebStation 的不一致；需手动编辑 CLI 的配置文件（路径类似：/volume1/@appstore/PHP82/usr/local/etc/php/php.ini），补上extension=mbstring.so等行 - 若卡在
guzzlehttp/psr7或symfony/polyfill安装，大概率是phar.readonly = Off没开，同样要改 CLI 的php.ini
部署 Cloudreve/Seafile 等 PHP 项目时 composer 的实际角色
像 Cloudreve 官方提供二进制包，其实不强制依赖 composer；但如果你改了源码、加了插件、或想用最新 dev 分支，composer 就绕不开——它负责拉依赖、生成自动加载映射、执行 post-install-cmd 脚本（比如生成 storage/app 目录权限）。
- 别在
/var/services/web下直接composer install：该目录属http用户，而 SSH 登录用户通常不是，容易因权限拒绝写入vendor/ - 建议在
/volume1/docker/your-project这类可读写路径操作，完成后把整个vendor/和composer.lock一起复制进网站目录 - WebStation 的 PHP 进程默认不读取用户家目录下的
.composer/，所以全局配置（如私有仓库 auth）得写进项目级composer.json或通过--repository参数传入
composer 最难搞的从来不是“怎么装”，而是“它以为自己在跑 PHP 8.2，其实底层加载的是 PHP 5.6 的扩展集”——所有报错都得回溯到那个 php -v 和 php -m 的路径，少一次核对，后面就多三小时排查。 
