@
raw0xff 你没搞明白的是谁在防谁。
这个机制不是让你服务器防着恶意客户，而是让正常客户防第三方网站的攻击。防止第三方攻击者在正常客户的浏览器中模拟正常请求访问你的接口。这个是在保护浏览器安全，不是保护服务器安全。
你的客户可能在第三方网站被钓鱼，假设没有同源策略，假设你是银行，此时恶意的第三方网站里有个脚本会在用户浏览器里运行：自动模拟你网站的转账操作，发给你的接口。由于没有同源策略，这个请求因为带着你客户的 cookie 等信息。你的客户就这样莫名其妙被偷了钱。
或者你是一个 webmail 但是人家也可以通过类似手段，在三方钓鱼网站里插脚本控制用户浏览器，进而偷到你客户的邮件。
你说请求在接口处理与否取决于你的代码，但是这个伪造的请求千真万确是客户端浏览器发的。看似完全正常的请求，正常的 Cookie ，同样的 IP 。Referer 头不靠谱而且可能被绕过，你说用 Token 但是 Token 也可能被偷(如果没有同源策略)。你服务器要怎么检查？？
因为这种攻击发生在客户端，所以客户的浏览器实现防御才比较容易。
于是有了同源策略 SOP ，注意，SOP 不阻止请求发出，但是可以阻止带着 Cookie 。还有非同源页面能否读网站响应。
你会发现请求不带 Cookie, 同时脚本不能跨源读数据，
上面说的两种攻击基本上就被阻断了。（当然实际情况更复杂些）
但是前后端分离也同样被阻断了。
你说的：
> "浏览器访问 a 网站时 a 网站的脚本访问 b 网站，无论是 post get 还是 options ，是否响应是 b 网站自身逻辑说的算的，即便 Access-Control-Allow-Origin:* 也只是告诉浏览器 b 允许所有来源访问，至于如何响应是看代码。"
带上 SOP 以后，由 a 发起的访问 b 网站的请求不会带有 b 的 cookie ，响应也未必能被 a 的页面读取。敏感操作和敏感信息都 a 都搞不了。
而 Access-Control-Allow-Origin 是 CORS 的一部分，作为同源策略 SOP 的扩展，允许你提供接口的服务器指定哪个网站可信(可以发 cookie 和可以读响应)，就是告诉浏览器第三方网站的白名单，白名单里的网站应该不会让浏览器发恶意请求，可以让 SOP 信任。CORS 给开发部署提供一些灵活性。这样你又可以前后端分离了。
顺便，你设置成 Access-Control-Allow-Origin:*的时候，浏览器的 Cookie 是不会发出去的。这整套机制都是怕浏览器被第三方恶意网站利用。
至于调试工具，，你不用调试工具当日常浏览器，不用担心被钓鱼，而且 CORS 也要被调试。所以当然不遵守这些。
楼上有人说的 CSS 应该是 XSS. 那个是 CSP 机制的事情。因为恶意脚本插入正常网站后是同源的。