本地全栈联调接入 HTTPS：谈谈 mkcert、真机调试与跨域 Cookie 的取舍

最近重构了一套本地开发环境，又遇到了老生常谈的真机联调与 HTTPS 问题。

现在浏览器的安全策略收得越来越紧，很多特性比如 WebCrypto、Clipboard API，或者第三方鉴权依赖的 SameSite=None; Secure Cookie，脱离了 HTTPS 环境在本地根本跑不通。一旦引入手机端真机测试，链路立刻复杂了一倍。

聊聊这几年我试过的几种解法和权衡：

1. mkcert + 本地反代：体验最接近生产环境，直接在开发机和手机上各信任一次 CA 根证书，性能损耗也最小。痛点在于移动端，iOS 信任证书需要进设置二级菜单手动开启，Android 7 之后对用户证书的限制更是麻烦，有时不得不改 Network Security Config。
2. 抓包工具代理（Whistle / Charles）：适合临时调试。但如果前后端端口不一致，遇到 CORS 预检请求（OPTIONS）和带凭证的跨域，排查配置往往要花不少时间。
3. 内网穿透（Cloudflare Tunnel / ngrok）：彻底绕开本地自签名证书的信任问题，直接拿合法证书。代价则是请求要出公网绕一圈，联调大文件上传或者低延迟场景体验会打折扣。

想问问大家，在日常的全栈开发流里，你们是倾向于花时间把本地的 CA 和反代基建一次性搭好，还是更倾向于用穿透工具省心省力？在处理跨域写 Cookie 这件事上，大家有什么更轻量的权衡方案吗？