确实，需要了解：
- 底层使用的设计模式
- 针对特定场景整了哪些反模式写法
- 用到了什么数据结构与算法
- 是否 hack 一些特殊的情况，自己以后实现也要注意
- ...

发现一些回答都没认真看问题，就回答了（当然我有时候也会犯这个问题）。
以为我没看文档，然后叫我去看文档。

同源请求在非 GET 和 OPTION 的时候会带上 Origin ，这我知道。但我无法理解这个设计，因为没有带上 Origin 的必要。

点击不少啊，回答却寥寥无几，还是离题的回答，说明这个问题确实比较偏门。
看懂问题的不知道答案，看不懂的一顿乱答。

HTTP 头字段只是标准，在什么时候缓存，什么时候不缓存。
浏览器理论上会遵守，但有些细节可能不会遵守，或者会变化，比如 Chorme 80 版本后将 Cookie 的 SameSite 由原来的 None 改为了 Lax 。
此外可能某个版本有实现上的 bug 。
在技术群，有个群友说他的套壳 APP ，设置了 Cache-control: no-store 没效果，还是拿到的缓存内容。我觉得可能是 APP 套壳的浏览器有问题。

所以，我想说的是，最好还是给文件名加哈希值，最稳妥。毕竟获取一个从来没访问过的资源，浏览器本地是不可能有缓存的。

要重构，单元测试要覆盖够才行。
然鹅国内一般都不写单元测试。
那坨屎一样的秘制逻辑业务代码，要考虑各种场景的赶时间的 hack ，谁敢改啊。

一般都是通过跑路解决的，不是吗？

@weixiangzhe 哦，这个是缓存。`Access-Control-Max-Age: 86400` 可以设置缓存时间。

有道理

mbp m1 香。
我是前端，最低配的 mbp 也够用了。而且我不玩游戏，也不用非主流的软件，非常适合我。
（最满意的是 mbp 的 类 unix 终端）

因为前端很讨厌解决浏览器兼容问题。
兼容这种东西做过的都知道，很费力，要写很难理解的奇怪的兼容代码，如果测试不提我根本不会兼容。

工程化嘛。

前端在过去很简单，JS 被发明的作用就是给网站加点小交互。
发展到现在，甚至直接就把桌面端的那一套搬到网页上了，比如谷歌地图、谷歌文档，这是非常复杂的大型项目。
如果你还像以前一样，直接写 html 、css 、js ，一堆人一起开发，还要考虑兼容问题，命名冲突问题，开发体验很差的，bug 也会多。
怎么办？用工具（比如打包工具、CSS 预编一起）、用框架（ JQ 到 React 和 Vue ）、用第三方库（ npm ）。

当然前端目前因为快速发展的原因，各种方案和轮子层出不穷，一些轮子可能解决了一些问题，但又带出了其他问题。于是修修补补，出现了新的方案。或者有人觉得不好，又重新定义了一个方案，又一个轮子出现了。

确实轮子太多了，但也要确实地明白，解决问题的方案并没有一个固定的答案，每个方案都各有利弊，要选择合适自己的才行。
我们再回到 “提高开发体验” 这件事情，提高开发体验有什么用？可以让产品有更好地交付、更少的 bug 。

我希望自己脑子里想一个东西，然后计算机自动帮我写好了，而且没有 bug 。但不太可能。

复杂是为了抽象，为了将日渐繁杂的业务抽丝剥茧，提高代码的可读性和可维护性。

@jimages 懂了，一个字段存两个字段的内容。

做自媒体嘎韭菜吧

可以考虑买京东京造的 K8 蓝牙机械键盘，感觉还好。苹果键盘倒是没用过。

CMD /bin/sh 配合 -td 可以让容器持续运行，不是很懂为什么。

这个我一看就知道其实是 TypeScript 的 enum 的编译为 JavaScript 的结果，是 TS 枚举的反射特性。

https://www.typescriptlang.org/docs/handbook/enums.html#reverse-mappings

enum Cute {
Red = 2,
Blue,
Yellow
}

没啥问题，编译用的模板越紧凑越好。

我觉得没太大必要，直接用一些静态博客的方案就好了，比如 hugo 、wordpress 、hexo 。
个人博客网站的时代已经过去了，看了下自己的博客访问日志，全是爬虫，绝了。
建议在一些主流的博客平台或者公众号发就好了，个人博客平台可以考虑作为备份。
另，我用的 hugo 的 MemE 主题搭建静态博客网站。

后端管理系统是比较没挑战的，都是堆需求，规模也不够大，通常用的技术栈也比较一般或者落后。
以后面试也没法提供一个可演示的地址。
如果可以尽量做 toC 的产品。

我是前端，线上的 bug 都不是紧急需求，基本没啥事，毕竟没掌握业务核心，混成一个切图仔。
你这个应该是后端，管理着业务核心，崩了就得立刻马上修，不然用户流失严重，混久了以后弄个中层管理不成问题。
前途光明啊。

不错呀，star 了。