技术博客
这是 Composer 用来指定访问 GitHub 仓库时默认协议的配置项，控制 composer install 或 composer update 过程中 Git 克隆依赖所用的 URL 方式。它不改变你本地 Git 的全局设置，只影响 Composer 自己生成的仓库地址（比如从 packagist.org 解析出的 github.com/user/repo）。
Composer 默认拒绝未经认证的私有仓库访问，直接 composer require 会报 401 Unauthorized 或 403 Forbidden。关键不是改 composer.json，而是让 Composer 知道“你是谁”——这靠 auth.json 文件实现。
直接写 "vendor/package": "dev-main#abc1234" 就行，Composer 会自动识别为「main 分支 + 指定提交哈希」。它不是特殊语法，而是 Composer 对版本约束的原生支持——dev- 前缀表示开发分支，# 后面是 Git commit hash 或 tag 名。
直接在包名后面加 dev-分支名 即可，Composer 会自动从对应仓库拉取该分支的最新提交。这不是“安装分支”，而是把分支当作一个开发版本（version）来引用。
这通常不是网络问题，而是 Composer 没法通过 SSH 访问私有 Git 仓库。Composer 默认走 HTTPS 协议拉取包，但你的私有仓库只开了 SSH（比如 git@git.example.com:org/pkg.git），而 SSH 密钥没配好或没被 Composer 正确使用。
直接装 dev- 开头的版本名就行，Composer 会自动识别为开发分支而非稳定版。比如想装 monolog/monolog 的 main 分支，命令是：composer require monolog/monolog:dev-main注意不是 dev-main@dev，也不是加 –stability=dev——后者只影响依赖解析策略，不指定具体分支。
这不是网络或配置文件语法问题，而是你提供的 GitHub Personal Access Token（PAT）缺少必要 scope。Composer 在拉取私有仓库时会用该 token 认证，若 token 没开 read:packages 或 repo（取决于仓库类型），就会返回 Invalid credentials，且错误信息不提示具体缺哪个权限。
直接说结论：100GB 数据可能 2 小时迁完，也可能拖 3 天——关键不在大小，而在你选的路径是否匹配当前环境。比如用 mysqldump 导出再导入 5000 万行 InnoDB 表，没调参的话很可能卡在单线程写入和频繁事务提交上；而用 xtrabackup 物理拷贝，同一份数据在千兆内网下通常 20–40 分钟就能完成全量复制。
群晖的 php 命令默认指向系统旧版（如 PHP 5.6），而 WebStation 用的是另一个路径（如 /volume1/@appstore/PHP82/usr/bin/php）；更关键的是，CLI 模式下即使你在 WebStation 图形界面勾选了 curl、openssl、json 等扩展，它们也大概率没加载——因为 CLI 读的是独立的 php.ini（通常在 /etc/php/cli-php82/php.ini），不是 WebStation 那套配置。
在 Linux DevOps 环境中，发布权限与审计不是“配完就完”的一次性操作，而是持续演进的安全闭环。核心原则是：最小权限可发布、每次变更可追溯、异常行为可感知。