看起来，你的需求 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 头，你就可以读到了，这个时间再加上通信的时间，就比较准确了

@keroppi 估计过了时间，这个问题已经被你放下了，昨天正好帮一个小伙儿看 cors 的问题，然后想起你这个帖子了。
梳理了一下，然后再结合你发的图，你的 PHP 的跨域配置中，设置了 Access-Control-Allow-Headers Content-Type, 但是 nginx 上并没有，而你的 Content-Type 正好是简单请求之外的。所以你把 nginx 的那项配置改为 add_header Access-Control-Allow-Headers X-Requested-With, Content-Type; 大概率应该可以了。

有一个工具：
https://github.com/mafintosh/why-is-node-running

@keroppi

回头看最初的报错，是 prefight 请求的时候没有通过 cors 检查，所以出问题的是 options 请求，不是 post 请求，因为不了解你的网络实际情况，不确定中间还有没有别的 nginx 之类的，所以你先用 postman，发一个 options 请求过去，看看返回的 header 里面的服务器信息，来确定到底是什么服务器回应了这个 options 请求

index.php
这个页面的 header 里面有 cors header
/ 这里会路由到比如你的默认页面，这个里面没有 cors header 吧？

@doctoroyy 你拿到了 250 部电影的信息，这个信息是包含了每部电影的 imdb 链接的，而这个 imdb 链接在豆瓣电影里面也有，你抓取豆瓣页面的信息之后，用豆瓣页面里面的 imdb 链接去匹配你 top250 电影列表的 imdb 链接，理论上就不会有任何出错的可能。如果用名称去匹配，存在可能性，当然可能性非常小，会有匹配错的情况发生（比如诺兰要重拍自己的记忆碎片，导演名和电影名都不变的话，你的方案就可能匹配错了）

@doctoroyy 你去爬取豆瓣的页面的时候，按你的描述，是拿导演和电影英文名做的匹配，但是豆瓣电影详情页上是直接有电影的 imdb 链接的，直接匹配这个链接不是更好吗？（虽然 250 部拿名称匹配出错的可能性也不大）

关于 IMDB 那个项目，豆瓣电影上就有电影的 imdb 链接，应该不需要根据导演和电影的英文名来匹配吧？是有别的什么原因做的这种选择吗？

@dtdnqsb linux对两种方式都支持，所以应该选什么都可以吧