HA 部署选型与落地 8 问：从装哪种到断网能不能跑，一次讲清判断依据

装 Home Assistant 这件事，绝大多数翻车不是发生在"配某个传感器"，而是发生在最前面那 8 个决策上——装哪种形态、数据存哪儿、要不要 HTTPS、权限怎么分、断网扛不扛得住、远程怎么连、备份做没做、崩了怎么回。这 8 问想清楚了，后面所有自动化和集成都不会再踩低级的坑；想不清楚，装完半年再补也来得及，但代价高得多。

我按"从装到跑起来"的顺序把这 8 问一次讲完，每问给判断标准 + 可直接照做的命令或路径。不是"什么是 HA OS"这种百科，而是"你这种情况选哪个、为什么"的落地判断。硬件侧刷机和接设备的具体步骤，参考 HA OS 部署实操 和 HA Docker 部署。

8 问的优先级（先定骨架，再填细节）

顺序	决策	定早了后面省多少事
1	HA OS 还是 Docker	决定整台机器归谁管，影响后面所有 Add-on
2	数据盘选型	决定寿命和流畅度，事后换盘要迁数据
3	本地 HTTPS	内网一步到位，事后加证书要改入口
4	2FA + 多用户权限	越晚加，越要把历史操作都迁移
5	断网本地协议	决定全屋抗断网能力，设备买完就锁死
6	远程访问路径	决定要不要绑云，随时可切
7	备份策略	一次设定长期生效
8	升级回滚预案	每次升级前 5 分钟做一遍

判断原则：前 5 问是"装之前必须定"的骨架，后 3 问是"长期运维"的底座。骨架没定就先别急着接设备，否则每接一个都是在给错误的地基加砖。

第 1 问：HA OS 还是 Docker，到底选哪个

这是新手装 HA 最容易纠结的点。我的判断标准就一条：你有没有一台可以 7×24 专门给 HA 的机器。

• 有闲置 x86 盒子（J4125/N100/迷你机）、有一台群晖/威联通、有一台 PVE/ESXi 虚机宿主机——直接 HA OS。它把底层 Linux、HA Core、Supervisor、Add-on 商店打包好了，UI 里点一下就能装 Mosquitto MQTT、Node-RED、Samba、ESPHome，全系统一键快照备份和回滚也都在 Supervisor 里原生支持。
• 只有一台已经在跑一堆业务的 Linux 服务器，不想再多开一台——选 Docker。代价是丢掉官方 Add-on，得自己用 docker compose 逐个起 Mosquitto、Postgres 等，备份也得自己管 volume 目录。

结论：除非你要把 HA 塞进现成的 Linux 里，否则无脑选 HA OS。 Add-on 商店和一键备份这两样体验，是 Docker 版很难补齐的。

Docker 版至少这样起一个最小可跑的组合（不是完整方案，完整部署看 HA Docker 部署）：

# 数据目录放 SSD，别放 overlay 层
mkdir -p /opt/ha/config /opt/ha/mqtt

# HA 本体（端口 8123 是 HA 默认 Web 端口）
docker run -d --name ha \
  -v /opt/ha/config:/config \
  -e TZ=Asia/Shanghai \
  -e USER_ID=$(id -u) GROUP_ID=$(id -g) \
  -p 8123:8123 \
  ghcr.io/home-assistant/home-assistant:stable

USER_ID/GROUP_ID 必须传，否则容器内用户和宿主机文件属主不一致，日志写不进去。

第 2 问：数据盘用 SD、SSD 还是 NVMe

HA 本体不是大头，真正吃盘的是 recorder（历史记录数据库） 和 Add-on 日志。recorder 默认记录每个实体每次状态变化，一个中等规模的房子（几十个传感器 + 灯）一天就能写进数据库几十到上百 MB，长期跑 SD 卡是灾难。

介质	适合场景	判断
NVMe / M.2 SSD	长期主力、实体多	首选，写寿命和随机读都最高
SATA SSD	已有 SSD 的盒子	够用，略慢于 NVMe
SD / TF 卡	临时试用几天	别长期跑，几个月掉速坏道

结论：正式装就用 NVMe 或 M.2 SATA SSD，SD 卡只当临时调试用。

装完可以收窄 recorder 的记录范围，只记你真关心的实体（门磁、主灯、温度），别把几十个一次性传感器全录进去，既省盘又省数据库膨胀：

# 在 configuration.yaml 的 recorder: 段
recorder:
  include:
    domains:
      - binary_sensor   # 只记门磁/烟感这类
      - sensor
      - light
  exclude:
    entity_globs:
      - sensor.power_*    # 排除高频刷功率的实体

第 3 问：内网要不要上 HTTPS

HA 默认 http://盒子IP:8123。同一局域网内任何设备都能嗅探到明文（包括你 2FA 的登录请求）。内网不是绝对安全的——接进同一个 Wi-Fi 的邻居设备、被攻破的 IoT 设备都可能在内网横向嗅探。

两条上 HTTPS 的路径，成本都极低：

1. 域名 + Let's Encrypt：把盒子绑一个内网可解析的域名（或直接用你注册的真域名 + 内网解析），签个免费证书，反代到 8123。
2. HA 自带反向代理 Add-on：装 "反向代理（reverse proxy）" 这个官方 Add-on，它直接管理 Let's Encrypt 证书，UI 里点几下就行，适合 HA OS 用户。

结论：内网也上 HTTPS 几乎是零成本，而 2FA 只有配合 HTTPS 才有意义——先 HTTPS 再 2FA，顺序不能反。

第 4 问：2FA 与多用户权限怎么分

家里不止你一个人碰这块系统时，权限一定要分清楚，否则家人误操作把自动化改了，你排查半天会发现是"鬼改的"。

• 管理员账号：开 2FA（设置 → 安全 → 两步认证），TOTP 手机验证码即可。
• 家人账号：建"普通用户"，只能控制设备和看自己的仪表盘，进不了"集成"和"自动化"的编辑页。
• 长辈面板：单独做一块 Lovelace，大字号、只放常开常关的几个开关，复杂配置界面别暴露给他们。

结论：以家里最不懂技术的那个人为体验基准做面板，管理员收紧权限、开 2FA，家人给只读控制权限。

第 5 问：断网了 HA 还能不能跑

这是 HA 相对一众云系智能家居的核心优势，但只有你的设备走本地协议才成立。

断网仍能跑的：Zigbee、Z-Wave、Matter、Thread、以及局域网直连的 Wi-Fi 设备（ESPHome、Tasmota、Philips Hue、小米 LAN 模式等）。门磁触发玄关灯、温湿度触发空调红外，这类联动全在局域网内自洽完成，拔掉光猫都照常毫秒级执行。

断网就停的：只给云端接口的封闭设备、远程 App 控制、在线 Add-on 商店更新。

结论：选型时认准"Works with Home Assistant"标识、优先本地协议设备，全屋才真正具备抗断网能力；纯云设备别指望它断网还能联动。

具体哪些协议是本地、哪些集成依赖云，参考 Zigbee 入门 和 Matter/Thread。

第 6 问：远程访问必须买官方云吗

不必。官方 Nabu Casa 云是一键免公网 IP 的省事方案，但要订阅费。要数据管道攥在自己手里，有两条免费路：

• Cloudflare Tunnel：在盒子跑一个 cloudflared，隧道直接打到你注册的域名，免公网 IP、免路由器端口转发，手机在外网走域名就能回 HA。详细操作参考 远程访问与外网安全。
• Tailscale / WireGuard：把手机和盒子组进同一个私网，手机"回家"了才连 HA，隔离性比 Tunnel 更强。

结论：远程访问别默认绑云——Cloudflare Tunnel 或 Tailscale 免费且可控，是运维侧更稳的兜底。

第 7 问：备份策略一次定好

备份不是"出事了才做"，是长期生效的一次设定。

• HA OS：Supervisor 默认会自动定期快照，但别只依赖它。设置 → 系统 → 备份 里手动做一次全量，并勾选包含 Add-on 数据（很多人备份默认不含 Add-on 数据库，恢复出来 Mosquitto、Node-RED 的配置就丢了）。
• Docker：没有 Supervisor 备份，必须自己把 /config 目录定期 rsync 到另一台机器或 NAS，把关键 Add-on 的 volume 目录一并带出去。

结论：HA OS 用 Supervisor 全量快照（含 Add-on 数据）并定期同步出机器；Docker 必须自己写 /config 与 Add-on volume 的异地备份，没有内置兜底。

备份与恢复的完整步骤、跨机器恢复怎么做，看 备份与恢复实操。

第 8 问：升级崩了怎么回滚

HA 大版本每月第一个周三发布，升级前一定先做一次第 7 问里的全量备份。升级后有 3 个判断点：

1. Repairs 面板：设置 → 系统 → 修复。升级若发现弃用配置或冲突，会主动弹卡片一步步引导你修，别无视。
2. 自动化 Trace：某条自动化升级后不跑了，打开它的追踪看是哪一步断了——是 trigger 没触发、condition 没过、还是 action 报错。
3. 回滚：前两样都救不回来，直接 Supervisor 里一键回滚到升级前快照，比重装快得多，别在原地反复改配置越改越乱。

升级与回滚的完整动作，参考 HA OS 升级与回滚。

结论：升级前必做全量备份，升级后按"Repairs → Trace → 回滚"三级排查，救不回就回滚，不要在错误方向上硬改。

8 问落地的最小动作清单

把上面 8 问收敛成一张可以照着做的清单，新装一台 HA 从上到下过一遍：

1. 定形态：有专属机器 → HA OS；塞进现成 Linux → Docker（第 1 问）。
2. 定数据盘：NVMe/M.2 SSD，收窄 recorder 记录范围（第 2 问）。
3. 内网上 HTTPS（域名+Let's Encrypt 或内置反代）（第 3 问）。
4. 管理员开 2FA，家人建只读账号，长辈单独做极简面板（第 4 问）。
5. 核心联动只用本地协议设备（Zigbee/MQTT/局域网），纯云设备不指望断网联动（第 5 问）。
6. 远程用 Cloudflare Tunnel 或 Tailscale，不默认绑云（第 6 问）。
7. 备份：HA OS 全量快照含 Add-on；Docker 自写异地备份（第 7 问）。
8. 升级：先备份，升级后 Repairs → Trace → 回滚三级排查（第 8 问）。

一句话总结：HA 的稳定性不是装完那一刻决定的，是装之前这 8 个决策决定的。骨架（前 5 问）定对了，后面加设备、加自动化都只是往上堆；定错了，每堆一层都是在给错误的地基加砖。把这 8 问先过一遍再动手，能省掉装完半年补窟窿的成本。

相关教程

• HA OS 部署实操：从下载镜像到首次启动的完整五步。
• HA Docker 部署：把 HA 塞进现成 Linux 的完整方案。
• 远程访问与外网安全：Cloudflare Tunnel / Tailscale 详细操作。
• 备份与恢复实操：全量快照、跨机恢复、Add-on 数据备份。
• HA OS 升级与回滚：升级前备份、Repairs/Trace 排查、快照回滚。