冷知识: Python 是强类型语言
强类型弱类型静态类型动态类型都分不清楚...看到「强类型语言是比脚本语言好很多」就不想看下去了

```C#
public class Program {
public static void Test(object param) {
Console.WriteLine(
param switch {
int a => a,
string b => b,
_ => throw new ArgumentException("error")
}
);
}

public static void Main() {
var arr = new List<object> { "abc", 123 };
foreach (object item in arr) {
Test(item);
}
}
}
```

是要这样的?

@GeruzoniAnsasu
「从宏观来讲，历史是无数小因果关系的多重积分，历史反映的是世界因果关系的全貌，如果反对历史存在，那么实际上是对因果关系和逻辑体系的否认和反对，这是轻而易举就可以驳斥的。」
当然可以否认因果的存在, 这并非轻而易举就可以驳斥, 即便是康德也不行. 把因果关系视为真理不容否认, 本身就是有问题的.
https://www.zhihu.com/question/20773047/answer/16133269
https://www.zhihu.com/question/20773047/answer/81306222

复制文件, 模板引擎填充变量...

其实找正规中介还挺靠谱的...每次换房都是直接在感兴趣的地段附近找线下乐有家, 中介带着一天看好几个房, 基本上两天就搞定, 省心省力, 也就多掏一个月房租
不用对中介如此抗拒, 只要是大点的正规中介都还行, 信息是有价值的, 要么自己费时费力去找, 要么花点钱交给中介
自己去找的话一般只适合找城中村的房, 那房东直租倒是比较多, 其次小区如果有公告栏的话, 运气好可以找到房东直租的, 其他路边电线杆的小广告基本上都是坑比小中介和二房东了

本质上是你的主观期望 node.js 的地址给你返回一个 js 文件, 但实际上没有任何规定服务端一定要返回个文件给你...他完全可以看一眼地址是 node.js 但是给你一个 node.cpp 或者其他任意什么...
地址就只是地址, 只是字符串, /node.js 和 /foo 没有本质区别, 之所以会有疑问仅仅是你先入为主的期望而赋予了 /node.js 不同的含义

编辑器的主题色挺好的, 代码的配色就有点不太和谐...感觉 import 的绿色和 const 的颜色太亮了些

底层点的就 Fastify, 封装比较全的就 Nest

还有几轮加息, 别说 2w, 1w 都是大有可能, 现在顶着加息入场怕不是脑子不好使

椰青, 每天下班回家路上买一个, 糖分比奶茶快乐水和其他果汁还是低不少的

你搞错了 rAF 的机制, rAF 只是帮你把函数注册, 插入到每一帧渲染的间隔时间里执行, 只要你的任务执行时间不超过 1/60s, 那你多次调用 rAF 注册一百个函数也没问题, 只要这 100 个函数总执行时间不超过 1/60s, 那他们就依然都是 60Hz

@golangLover 那也是.net 6 的事了
微软的命名确实很蠢, .net, .net core, asp.net, asp.net core, 但是之前说的这些人, 说传统行业用.net 的, 显然他们连.net core 是什么都不知道更不用说知道这个命名演变了

这帖子里还有这么多人分不清.net 和.net core...

@pppan 这么多回复里就这个说到点子上了

@duke807 我从来就没有说过一定要用 cookie, 我只是针对楼主的问题作出回答, 请不要把这样的观点强加到我身上
而针对你说的, 你用 refer 也可以选择是否给予服务, 的确, 但这只是你 a.com 和 b.com 私下的协议, 浏览器并不知情, 确实如你所说你自己做好判断能够保证资源不被其他站点获取, 一方面这仅仅针对 http 请求, 另一方面这样私下的协议浏览器并不知情. 当然你可能会问为什么要浏览器知情? 如果每个开发运维人员都能够很好的做好安全措施, 那这个世界的确会美好很多, 但显然不是这样的, 依靠这些判断来保证安全增大了开发和运维的心智负担, 大部分人都做不好, 而浏览器作为 web 的入口, 他选择承担让 web 更安全这样的责任, 提供了这样的机制, 是有意义的
而回到这个帖子, 我不知道为什么这么多人把目光都放在 cookie token 这样的东西上, 同源策略不仅仅是针对这些东西的, 它限制的内容很多, 而 cookie 仅仅是其中之一而已.
事实上同源策略还限制了很多 js API, 包含了跨域写, 跨域读, 跨域嵌入资源几个方面, 而限制主要体现在跨域读这件事情上, 比如 a.com 引用了 b.com 的图片, 如果没有 cors 允许, 那 a.com 页面的 js 不能读取图片的二进制内容, 而图片的二进制内容可能泄漏敏感信息, 当然这个例子可能并不能感受到, 一个图片能泄漏什么敏感信息. 但同样的, 假如 a.com 用 iframe 嵌入了网银登录页面, a.com 的 js 能够读取嵌入页面的变量, hook 里面的函数, 那显然是有问题的. 当然你也可以用 X-Frame-Options 来防止 iframe 嵌入, 但是同样地, 如前面所说, 并不是每个人都知道使用这些来保证安全, 而浏览器替他们完成了这一保障总是好的

"为什么浏览器不能在检测到是 a.com 发出的请求时，不携带 b.com 网站保存的 cookie 呢？"
仅针对这一句回答, 有没有可能, 我是说可能, b.com 其实希望接受这个 cookie 呢? 你这个方案相当于假设了 b.com 不需要这个 cookie, 直接剥夺了 b.com 的选择权, 而浏览器给了 b.com 这样的选择权
很多人认为同源策略的目的是为了防止某类攻击, 是为了保护什么, 但是同源策略本身的意图真的是这样吗? 还是你们一厢情愿地这么认为? 同源策略仅仅是浏览器框架下为 a.com 和 b.com 提供了一套交互的规则, a.com 索取资源需要在这个规则下完成, 而 b.com 有权利选择是否给予, 当然这一切都是仅限于浏览器框架内. 同源策略保护了什么吗? 当然的确也在某些方面提供了保护, 但那是它全部的设计意图吗? 把同源策略的目的理解为防范攻击未免过于一厢情愿和狭隘了.
毕竟如果你真的想要不经过 b.com 的同意获取资源, 那大可以写爬虫, 但这已经脱离了浏览器框架内了, 不是同源策略要考虑的问题, 而在浏览器内, 同源策略保护了 b.com 的同时, 也给 b.com 留下了选择的权利, 而你的方案里, 显然没有给 b.com 提供任何选择的机会, 充满了独裁意味
而如果考虑有没有必要给 b.com 这样的选择, 那当然是有必要的, 当你的业务足够多, 需要多个子域名区分, 同时又希望它们之前能够有一些资源上的交互, 并且仅限于自己公司下几个域名之间而不想给其他域名获取你的资源, 那就有必要了

西方哲学史, 斯通普夫的
不推荐罗素的, 感觉没那么客观

初衷(指某种主观意愿而非客观事实
尽信书则不如...