acme.sh 的重点不是申请证书，而是把续期风险管住

acme.sh 是一个很典型的基础设施工具：第一次使用看起来只是几条命令，真正的门槛却在长期治理。证书会过期，DNS token 会泄露，reload 脚本会失败，Web 服务器路径会变化。一个 ACME 客户端是否可靠，不能只看它能不能签出第一张证书，而要看它能不能把这些边界长期收住。

官方仓库显示，acme.sh 是纯 shell 的 ACME 客户端，GPL-3.0 许可，主语言几乎全部是 Shell，支持多 CA、多验证方式、DNS API、deploy hook 和通知 hook。它默认支持 ZeroSSL，也支持 Let’s Encrypt、Google Public CA、SSL.com、Actalis 以及 RFC 8555 兼容 CA。

不要把证书工具当成一次性安装脚本

很多事故不是因为 ACME 协议复杂，而是因为团队把证书管理当成“装完就忘”的小事。acme.sh 安装后会创建 daily cron，这很好；但 cron 是否真的运行、续期失败是否通知、reloadcmd 是否有效、证书文件权限是否符合服务要求，都需要明确验证。

更稳的做法是把它纳入配置管理：安装路径固定，域名清单固定，签发方式固定，部署 hook 入库，日志路径和通知渠道可查。这样换机器、换运维、换 Web 服务时不会靠记忆恢复。

DNS-01 的便利和代价

DNS-01 能解决通配符证书、内网站点、不可公网访问服务的验证问题。acme.sh 的 dnsapi 生态很丰富，这也是它被 NAS、路由器、Proxmox、自托管面板和各种轻量服务器采用的重要原因。

但 DNS-01 把风险转移到了 DNS 凭证。一个能自动写 TXT 记录的 token，如果权限过大，也可能被滥用来劫持解析。团队应该用专用 token、专用权限、专用运行账户，并明确 token 更新流程。对个人服务器，也不要把主 DNS API key 塞进随手复制的脚本。

deploy hook 才是生产边界

签发证书只是取得材料，真正影响线上服务的是部署。acme.sh 的 deploy hooks 覆盖了常见 Web、网关、存储、网络设备和管理面板。它们能减少手工复制证书的混乱，但也要求你把 reload、权限、路径和失败处理写清楚。

先在测试域名或 staging 环境验证签发。
确认服务读取的是 install-cert 输出路径，而不是 ~/.acme.sh 的内部管理路径。
把 reloadcmd 做成可重复执行的安全命令。
对 DNS token、证书私钥和日志做最小暴露。
至少每月主动检查一次续期任务和通知链路。

适合谁，不适合谁

acme.sh 很适合自托管运维、轻量云主机、边缘设备、多域名小团队和希望避开重型依赖的人。不适合完全没有命令行维护能力、没有凭证管理意识、也不愿意看日志的人。工具越轻，人的运维纪律越重要。

判断是否采用它，不是看 README 里的命令够不够短，而是看你能不能把证书、DNS、部署、监控和回滚连成一条稳定链路。