给本地开发接 HTTPS 前，我会先把 mkcert 的信任边界写清楚
做前端调试时，HTTPS 很容易被拖到最后一天才处理。等到要测 Service Worker、Secure Cookie、WebAuthn、摄像头权限或移动端真机调试，临时自签证书又会把浏览器警告、证书信任和团队环境差异一起带出来。我现在会把本地 HTTPS 当成开发基础设施的一部分，先用 mkcert 建一条只服务本机和开发域名的信任链。
从本地 CA 到开发服务器再到浏览器信任的安全边界示意。 来源：Codex image generation
为什么先看 secure context
MDN 的 Secure Contexts 文档说明，很多强能力 Web API 只在 secure context 中可用，目标是降低中间人攻击带来的风险。文档也提到 http://localhost、http://127.0.0.1 和 http://*.localhost 这类本地来源通常可被浏览器视为可信。这个便利适合单页原型，但一旦你要接自定义开发域名、跨设备访问、反向代理或真实 Cookie 策略，单靠 localhost 就不够稳定。
mkcert 解决的是本地信任链
mkcert 的 README 把定位写得很直接：它用于生成本地受信任的开发证书，几乎不需要配置。典型流程是先运行 mkcert -install，让工具创建本地 CA 并安装到系统信任库，再为 localhost、127.0.0.1、::1 或项目自己的测试域名生成证书和私钥。它还支持 macOS、Windows、常见 Linux 信任库、Chrome、Chromium、Firefox 以及 Java 场景。
这里的关键边界是：mkcert 会生成证书，但不会自动替你配置开发服务器。以 Vite 为例，官方 server.https 配置接收 Node https.createServer() 的选项对象，并明确说明需要有效证书，也建议创建自己的证书。落地时我会把生成的 cert.pem 和 key.pem 放进本地开发目录，通过环境变量或只在 dev 配置中读取，避免把开发私钥误带进构建产物。
root CA key 要单独保护
真正需要强调的是 rootCA-key.pem。mkcert README 明确警告，这个文件拥有拦截本机安全请求的能力，不能分享。团队协作时不要把自己的 CA 私钥发给同事，也不要提交到仓库。每个人在自己机器上安装 mkcert，各自生成本机证书；如果要让手机或测试设备信任，只复制 rootCA.pem 这类 CA 证书，并按设备说明安装，私钥仍然留在本机。
我的落地清单
第一步，给开发域名定范围，只写 localhost、*.localhost 或团队明确拥有的测试域名，不把公网顶级域名随便塞进配置。第二步，证书文件只进入 .gitignore 覆盖的本地目录，仓库里提交生成命令和配置模板。第三步，Vite、Node、反向代理和移动端调试分别写明读取哪一份证书。第四步，离职、换机或证书异常时重新生成本地 CA 和证书，不复用旧私钥。
这套做法的价值不在炫技，而在减少环境噪声。浏览器看见的是可信 HTTPS，开发服务器拿到的是明确的 cert 和 key，团队保留下来的是可复跑说明和风险边界。等项目上线时，生产证书仍然走正式 CA 和自动续期，本地 mkcert 只负责开发体验和调试一致性。