Bluehost Starter 部署 Composer：先锁定 PHP、扩展与依赖

从项目合同开始，不要只看 Composer 标签

Bluehost 说明共享服务器预装 Composer，并给出 Composer 与指定 PHP 版本的完整路径；执行前需要启用 SSH。官方也明确，支持团队不会代为排查自定义 Composer 命令或依赖冲突。

购买前收集 `composer.json`、`composer.lock`、PHP 版本、扩展列表、安装后脚本与可写目录需求。没有锁文件，部署时会重新解析版本；有锁文件，`composer install` 才会使用已记录版本。

让网站 PHP 与命令行 PHP 一致

Bluehost 允许在 Portal 或 MultiPHP Manager 中选择 PHP；Shell 命令若不写完整路径，仍可能调用另一套二进制，因此官方指南示范了完整 `ea-php` 路径。

在非生产副本记录网页 PHP、CLI PHP、Composer 版本和 `composer check-platform-reqs` 输出。网站与命令行版本不一致时，安装可能只对错误平台成功。不能用 `--ignore-platform-reqs` 掩盖差异；该参数会跳过本应核对的 PHP 与扩展条件。

Bluehost 当前帮助页对共享主机最低 PHP 版本存在冲突：一页写 7.4，模块和 handler 指南则写 8.1。不要把任何一项当承诺；应以准确账户实际选项为准，并选择应用兼容、仍受 PHP 官方支持的分支。

把扩展与资源当作购买门槛

项目可能要求 `ext-intl`、`ext-zip`、`ext-gd` 等扩展。Bluehost 说明共享主机模块随 PHP 版本而变，也不会为共享账户任意安装模块。 本地安装成功不能证明服务器条件相同。

用准确锁文件和目标 PHP 测试。扩展不可用时，应调整应用或依赖，或选择允许相应服务器控制的主机。ignore 参数能下载文件，不代表兼容。

Composer 解析依赖也可能消耗内存。Bluehost 虽展示命令级内存设置，共享账户仍受进程和资源限制。一次安装与应用长期 CPU、内存、执行时间和 worker 需求是两回事。

发布使用锁文件，更新放在受控环境

发布时对已提交锁文件执行 `composer install`。`install` 复用锁定版本，`update` 则重新解析并改写锁文件。 更新应在开发或 CI 完成：审查差异、测试、提交新锁文件，再部署已测试版本。

Namecheap 与 SiteGround 的同意图资料也把 Composer 与 SSH、PHP 兼容及完整发布流程结合；它们不定义 Bluehost 权益，但证明了相同决策方式：工具只是门槛，不是应用保证。

不要在没有回退点时直接在 `public_html` 更新依赖。Composer scripts 可以执行项目代码。先备份数据库与当前版本、审查脚本，尽量部署到 staging 或版本目录，再通过健康检查后切换。

区分构建成功与运行适合

安装完成只证明依赖在一个已核对平台放置成功，不代表应用适合 Starter。Bluehost 共享主机没有 root 或 sudo，不支持常驻进程，并受账户限制。

扩展、权限、数据库和请求都符合时，请求式 PHP 网站可以适用；常驻队列、自定义服务或依赖不可用系统组件的项目应选择其他平台。定时器能触发有边界任务，但不会变成常驻进程管理器。

用合成数据测试最长请求、上传、迁移、缓存、邮件、日志和一次回退。只打开首页不能算验收。

六步决定是否购买

1. 提交并验证锁文件。 2. 让网页 PHP、CLI PHP 与应用要求一致。 3. 不使用 ignore 参数核对扩展。 4. 在一次性副本验证脚本和目录。 5. 证明不需要不受支持的常驻进程。 6. 保留已测试的文件与数据库回退，并指定负责人。

当应用属于请求式 PHP、准确账户具备扩展、锁文件可重复安装、运行过程符合共享主机边界时，再选择 Starter。需要 root 包、常驻 worker 或自定义服务时，应选择 VPS 或应用平台。

六道门通过后，再打开已批准的 Bluehost Starter 直链。符合条件的购买可能为 Toolnavia 带来佣金；这是账户持有者已核实的 Bluehost 原始追踪链接，不保证部署结果或数值价格。