用途：该技能聚焦 Drupal 部署安全性，针对“本地通过、部署到生产后失败或静默丢失数据”的场景，帮助在规划或执行部署、编写 hook_update_N / hook_post_update_NAME / Drush 部署钩子时识别风险。资料标注验证环境为 Drupal core 11.4、Drush 13.7、drupal/custom_field 4.0.8、Composer 2.x，命令示例使用 drush @<alias>。
主要能力：
- 说明部署不等同于代码推送，区分仅配置变更、数据转换与无法用导入和更新钩子表达的步骤，并给出对应机制。
- 给出目标环境的部署尾部顺序：循环执行 drush @<alias> updatedb -y 与 updatedb:status 直到无待更新，再 cache:rebuild、config:import、cache:rebuild、deploy:hook，最后用 config:status、updatedb:status、deploy:hook-status、maint:status 校验。指出 update 钩子先于配置导入运行，因此不能依赖本次导入才出现的配置、字段或模块；需要此类依赖时改用 Drush 部署钩子。
- 维护模式残留：updb 若被杀死（OOM、超时、SIGKILL、SSH 断开），恢复维护模式的操作不会执行；重试 plain updb 也不恢复。用 drush @<alias> maint:status（退出码 3 表示仍开启）检测，更新清理完后用 maint:set 0 与 cache:rebuild 显式关闭。
- custom_field 的 addColumn/addExtraColumns/removeColumn 采用先 TRUNCATE 再分批回填的模式，中断可能丢数据，且钩子已记录为已执行，常规重试不会重跑。建议在同一钩子内先做快照（按表映射取专用表名，核对行数），并给出取证方向：检查 batch 表、drupal_batch:<batch id>:<set> 队列项、custom_field 恢复日志、行数对比；注意队列与 batch 数据约 10 天后被清理。
- 外部共享资源写入的更新钩子会因每个数据库各执行一次而重复触发，建议改为一次性 Drush 命令或脚本、用自控的持久状态做幂等门槛，并将已完成钩子保留为同号空操作。
- 服务定义参数数量必须与构造函数匹配，否则容器重建后抛出 ArgumentCountError，甚至导致用于恢复的 drush cr 也失败；建议编写不启动容器的静态 arity 单元测试。
限制：资料仅覆盖被验证的版本范围，其他版本行为暂未提供；升级或恢复步骤需在自身环境核对服务 ID 与签名。