Home Assistant 的容器部署重点，不是页面跑起来，而是设备发现、配置备份和更新回退。

\n
Home Assistant 和普通 Web 服务不太一样。很多服务只要端口通、数据库连上就能用，Home Assistant 还要和局域网设备、广播发现、蓝牙或 USB 网关打交道。容器部署能让配置目录清楚、迁移更简单，但网络模式、设备映射和更新节奏都要提前想好。

配置目录就是核心资产

Home Assistant 的 /config 目录保存集成、自动化、仪表盘、实体命名、用户设置和历史数据库。容器可以删，配置目录不能随手动。我的挂载会写得很直接：./config:/config，并把这个目录放进高优先级备份。升级、安装新集成、批量改自动化之前都先做快照。

配置目录里有些文件适合进版本记录，例如 YAML 自动化、脚本、仪表盘配置；有些包含令牌或敏感连接信息，不适合公开同步。我的做法是备份完整目录，但写文档时只记录结构和恢复步骤，不贴敏感内容。

设备发现决定网络模式

很多智能设备依赖 mDNS、SSDP 或局域网广播发现，bridge 网络下可能看不到。host 网络通常更省心，但它也意味着容器直接使用宿主机网络，端口冲突和访问控制要自己管。是否使用 host，不应该照抄示例，而要按实际设备验证。

如果有 Zigbee、Z-Wave、蓝牙网关或 USB 设备，还要确认设备节点映射和权限。设备路径最好使用稳定 ID，而不是每次重启可能变化的临时名称。接入新硬件时，我会先让 Home Assistant 识别设备，再写自动化；不要设备都没稳定，就开始设计复杂场景。

网络设备的命名也要固定。路由器里给网关、传感器桥接器和 Home Assistant 主机保留地址，能减少发现结果漂移。设备换位置、换电池、重入网之后，我会先看实体 ID 是否变化，再决定要不要修改自动化。

仪表盘也属于维护对象。家人日常使用的按钮、场景和状态卡片要保持简单，复杂调试信息放到管理员视图里。这样设备异常时，普通用户能快速判断是灯、插座还是传感器离线。

日志保留也要适度。设备频繁离线、自动化失败、集成登录过期，都要能在最近记录里找到线索，但不需要把调试日志长期打开。

关键自动化改动后，我会留一天观察窗口，再删除旧规则。

services:
  home-assistant:
    image: ghcr.io/home-assistant/home-assistant:stable
    container_name: home-assistant
    network_mode: host
    restart: unless-stopped
    volumes:
      - ./config:/config
      - /etc/localtime:/etc/localtime:ro

自动化先低风险试运行

灯光、插座、门窗传感器、空调这些设备接入以后，很容易让人想把所有动作自动化。我的经验是先从低风险场景开始，例如夜间小夜灯、离家提醒、温湿度记录。涉及门锁、电源、供暖、安防的规则，要有更严格的人工确认和回退方式。

每条自动化都要能回答三个问题：触发条件是什么、动作影响谁、异常时怎么停。排障时先禁用最近新增或改动的规则，再看设备状态和日志。很多“设备自己乱动”的问题，并不是设备坏了，而是自动化循环触发、条件判断太宽或多个规则互相影响。

更新风险要单独管理

Home Assistant 更新频率高，集成和前端变化也多。我不会让它无条件自动更新。升级前看发布说明，确认自己使用的关键集成有没有破坏性变更；升级后先看日志、设备状态、自动化执行记录，再让家人恢复日常使用。旧镜像和配置快照至少保留一个观察周期。

遇到升级后异常，第一步不是重装，而是确认配置目录是否可读、数据库是否迁移、关键集成是否报错、设备发现是否正常。能回滚镜像时先回滚镜像，配置已经迁移时再评估是否恢复快照。Home Assistant 的稳定性来自克制更新和清楚记录，不是来自一次性把所有设备接满。

Home Assistant 在 HomeLab 里很有价值，但它管理的是现实世界的设备。配置目录要备份，设备发现要验证，自动化要灰度，更新要有回退。只要这几件事做好，容器部署会让它更易维护；否则它会比普通服务更容易把小故障放大成生活里的麻烦。