一般来说，服务端不存在 window 和 document，所以可以通过
typeof window === 'undefined'
typeof document === 'undefined'
来判断。而且对于组件尤其要注意当前的环境

前端项目使用 k8s 通过 CI/CD 来编译和部署项目，而且一旦线上发布的代码有问题，可以先及时回滚到旧版本，然后修复上线。
前端有一些文件，比如 web-worker 和 wasm 文件不适合上 cdn 。所以也不推荐 html 上 cdn 。

基本上是启动 node server 的方式，css 、部分 js 、图片等上传到 cdn 。
node server 不仅仅作为静态资源服务器，还要提供接口代理的能力，毕竟接口的提供方来自好几个部门，有一些跨域、http （项目是 https 的）的问题，全部交给 http-proxy 来解决。

不合理

我是用手机 qq 解封的。我好几个 qq，只有那一个号被封了两次，其他的号都没事。我用的 mirai 。

imagemin: https://github.com/imagemin/imagemin

初学者注意：父调用子组件方法千万不要这么写

我可以做到定期更新依赖版本，定期删除不推荐使用的依赖（废弃的或者可以原生实现的），更新依赖时阅读依赖的更新说明，报错时可以找到问题的原因并回退版本等待修复或者参与修复。所以我不锁版本，避免留下屎山。

用了，这个也不算新东西吧

一样的工资，你非得去累死累活的加班的地方，还落个外包的名头图啥？真以为重新定义的外包就不是外包了？

当初为了实现多文件上传并限制同时上传数，写的一个实现队列的方法，你可以拿去参考参考
https://github.com/duan602728596/Q/blob/main/src/Queue.ts

可是 B 站并没有禁止 debugger 啊

redux 本来就不适合在组件里用。redux 适合用来保存全局状态，跨组件调用方法、获取变量。我的项目里用的是 redux-toolkit，感觉这个用起来比 redux-saga 舒服多了。

redux 就好比电线、组件就好比电器。电器电源线插到插座上就能用，但是不代表电器里面的所有线路都要接到电源线上。就像星际里的卡拉，虽然神圣的卡拉连接着每一个人，但是每个人的思想、状态还是有区别的。

你这种流程，完全可以用一个 hook 来代替，比如这样：
```javascript
const {
loading, // 加载状态
getData, // 获取数据的方法，可以用来重新获取数据
data, // 数据
... // 其他状态，比如数据总数、分页之类的
} = useRequest({ /* 配置 */ });

```

状态全放在 redux 里这种用法，我以前在项目里碰到过，我接手后给我留下一堆问题。比如有定义了一堆的 action type，导致一个流程的代码跳来跳去，action type 看不出来是做什么的；还有就是组件的所有状态被扔到 redux 里边，导致组件不能被复用的。

组件不要用 redux，你这么做，如果多个相同组件存在，却公用同一个状态，会出问题的。
内部可以考虑使用 useReducer 和 useContext 配合使用。

我之前是通过越狱了的手机安装 ssl-kill-switch2 抓的

分工，UI 没有要求只是没有人设计，但是交互体验还是要有的。我们开发的后台，同事有使用起来不舒服的地方，都是群里喊人私聊反馈然后修改的。
而且多个后台可能对应多个项目的接口，不分开的话，代码复用就会很麻烦。
后台之间也可能会需要封装成组件来复用代码。

其实 jsdom 、cheerio 、linkedom 是可以在浏览器中使用的，只不过没提供浏览器能使用版本而已。
我现在在浏览器中处理 html 就是用的 DOMparser 和 cheerio （因为 DOMparser 不能在 webworker 的环境中使用）。
不过看来 LZ 也不一定会用 webpack 和 rollup，还是用 DOMparser 吧。

原生的选择上面已经说了，用 DOMParser 。
用库解析的话就可以考虑 jsdom 、cheerio 、linkedom