ligolas

看起来，你的需求 mkcert, https://github.com/FiloSottile/mkcert 完全能满足

@lerosua 给楼主点赞，个人而言，我有过几次想查历史天气的需求，但是每次费力找了找就放下了，所以个人使用场景确实少。然后 @Loi 提到的场景应该是有意义的，季节性周期太笼统了。比如说采收，可能实际操作中需要的是连续晴天多长时间（干燥度足够适合采收）。或者可以把历史与预报结合起来用，提供相应的建议。

@autoxbc 恩，在发完之后我继续回忆了我测试的场景，应该是主站（静态页），cdn 加载 js，然后 API，三个独立的域名，js 试图读取的是 API 的 response 的 header 。

@autoxbc 你是对的，我之前的实验有问题，执行的 js 是从 cdn 上取的，相当于没有测试过同源的情况。不过考虑到现在服务部署的方式，很多时候资源就是从 cdn 部署的，并不能保证跟主站同源，这个 CORS 还是很有可能需要的（就像我遇到的情况），非常感谢你指出了我的盲区。

@autoxbc 所以我前面指出你就没理解对 CORS 的设计目的。CORS 是浏览器行为，是为了防止在浏览器端发生泄漏，服务端只是配合。那么浏览器端怎么发生泄漏呢？那就是 js，也就是如果某一个 js 执行了一段代码，读取到了**被认为**可能泄漏隐私的消息，这时候再发起一个到第三方的请求(可以是 js，也可以是 img ），就相当于把信息传递出去了，这个过程就被认为发生了泄漏。那么浏览器怎么做呢？其中一点就是限制了默认情况下 js 可以读取的 response header 的字段，也就是给你的文章里面的那 6 个，其他的，就得服务器端配合配置了才能由 js 读取到，这里面就包括了 date 字段。（另外不要弄错了，你通过开发人员工具是能读到的，cors 保证的是 js 代码读取不到）

@autoxbc 我确定你没搞懂 CORS 里面的 Cross-Origin 指的什么场景，到底哪里会 Cross Origin，为什么要做这个限制。
https://developer.mozilla.org/en-US/docs/Glossary/CORS-safelisted_response_header，注意这篇文章的标题：CORS-safelisted_response_header，点开链接看一下，然后再好好理解下 CORS 的本质。

@autoxbc 自己的前端是什么概念？ cors 是浏览器端的机制，只要用户还在使用正常的，版本不是特别老的浏览器，读取 header 就必须遵守 CORS，你自己尝试一下不难

@Hoshinokozo 通信时间就用本地计时的差值就可以，至于精度，可以根据需求来呗，他的核心需求是客户端时间不准是因为没开 ntp 对时，所以估计是差异很大，需求可能只是要求一个跟服务器尽量统一的时间，如果精度要求不高，可以就用 Date 的差值其实也就可以了。如果需要精度高一些的，可以用 performance.now()

response header 里面默认就带有服务器时间的，Date 字段，但是因为 CORS 的原因，你默认读不到，可以在服务器端配置一下 cors 头，你就可以读到了，这个时间再加上通信的时间，就比较准确了