1. api server 的地址可以单独放在同一个文件里，这样前后端都可以 import 这一个文件
2. 端口可以使用环境变量，包括前端的打包和 node server
3. 部署服务的话，我之前的公司用的 k8s ，所以上线真的没有这么麻烦
4. C 端：请求 API 用的 1 方案，这样主要是为了跨域（因为为了兼容 IE 用的 jsonp ），以及按需返回数据
内部系统的话直接配置 proxy 解决跨域问题

是的。而且 esm 引入 cjs 模块的成本不大，cjs 通过 import()仍然可以引入 esm 模块。

因为用 js 比较好实现，轮子都是现成的。
比如现在实现一个简单的 serverless 服务，关键依赖：glob 、express 、pm2 ，都是很早就出现的轮子。

“对程序员来说，语言不重要”：前提是，你的常用语言，得像 C 、C++、Java 这种，要么比较底层，要么岗位多，机会多。这样学别语言才有好的底子，而且能扛住转语言的风险。

项目里的原型链和面试时候的原型链是两种

master 分支不允许 push ，只允许提 pr 。pr 先跑一堆 lint 和 hook ，不过不允许 merge 。不 code review 不允许 merge 。

所以说还是直接上 lint 比较好

我一个做了三年的项目都没有启动不起来过

举个例子？

用 Angular 做 SSR 的网站，目前为止一个都没见过......

SSR 时，一部分的数据（比如首屏加载的数据）是从后端获取的。
输出 html 的同时也会输出 initialData ，比如 b 站会有 window.__INITIAL_DATA__，为了保证数据的一致性，渲染不会出现差异。
通过 ajax 获取的数据本来就没有必要在后端提前获取数据，所以什么都不输出或者只渲染个骨架屏是正确的做法。

1 、配置修改比较麻烦。比如我想在 ts 后面加几个 babel 插件，或者加个处理其他文件类型的 loader ，或者加个 plugin ，都不好处理。
2 、api 很多，查询起来比较麻烦，具体的可以见 ng 的 api 列表。
3 、有一些网站，想要做 SSR 多页应用，vue 、react + express 、koa ，比如哔哩哔哩，这种前后端分离的架构，angular 不适合，需要自己搭建环境，然后为了统一技术栈，后台系统更不会选择 angular 。
4 、vue 和 react 可以不依赖开发环境，引入脚本就可以执行（ react 额外引入 @babel/standalone 就可以支持 jsx ），学习成本低。

@yazoox 所以你才需要把 webpack.config.js 修改为 webpack.config.mjs

@yazoox Top-level await 只支持 ESM 模块

其实是可以的，关键词：Top-level await

报错原因都写了啊，你在 commonjs 环境中引入了 ESM 的包，所以报错啊。
然后像 react 、react-dom 、react-router-dom 这种包就不要放到 dependencies 里了，放 peerDependencies 里吧。

1 、建议把 title 改一下
2 、建议把 select 的 user-select 设置为 none
3 、前期过度会挡住装备查看的弹出层

魔法少女小圆
吹响吧！上低音号
五等分的新娘
擅长捉弄的高木同学
伪恋
因为太怕痛就全点防御力了
女友成双
赛马娘
转生成为了只有乙女游戏破灭 Flag 的邪恶大小姐
地狱少女
影宅
龙先生，想要买个家
青梅竹马绝对不会输的恋爱喜剧
剃须，然后捡到女高中生
学园默示录
pop 子和 pipi 美的日常
辉夜大小姐想让我告白
从零开始的异世界生活
打了 300 年的史莱姆，不知不觉就练到了满级