到你做的时候 面对的就不是那么好说话的了 分分钟把你的报价砍到没剩

恒温阀

我之前做主管的时候招前端，感觉最多的人的项目经历很喜欢写用了 A 做了 B 写了一大堆，每次看到都有点头晕。
其实简介就能知道你有什么技术栈了，不需要强调用什么做什么，而是去描述这个项目的一些可以说的亮点（可以吹的点），用什么做出这些亮点可以留到实际面试时说出来。

硬件的确很有意思，想起了大学的时光。
工作后有时也会想干硬件，总觉得硬件比起互联网可能会少点逼事，因为硬件开发要经过 OP 所说的一系列流程，拍脑袋出需求的成本太高，很难出现「快速迭代，扭头就改需求」这种行为。

参与一下

前端在研发链条末端，往往话语权更低，毕竟一般概念上都是没有后端接口不行。
但链条反过来也不是不行，只要前端写的屎山够大，改不动了也能翻转驱动后端对接前端（狗头

多年工作的体会，关于前后端对接格式这些东西，我觉得这是话语权的问题，没有规范约束的情况下就看谁能说服谁，也可以说谁先妥协。
遇到赖皮的前/后端，如 OP 举的例子，好说话的一方总会妥协地处理掉了。
除非你直接摆烂说不按照需要的返回我就不干了，把问题往上反馈也是一样看主管方的话语权大。

说到底还是要有规范，而且还要不断根据不同对接场景迭代的规范。

超级加强版的 chii 呀，666 。
以前也有开过脑洞，能不能把 chii 部署到远端然后整个团队共享使用。

分母打卡

支持一下

确实有兴趣就去找点保有量大点的机子咯，偏门的估计维修起来比较费劲

可以买 写ルンです，富士的一次性相机，确实感兴趣的再加钱吧（狗头

噢，我错了

alias
https://stackoverflow.com/questions/56134857/how-to-install-npm-package-under-alias-or-different-name

1. AST 可以的，写代码分析下树。
2. 另外一种方式，我开个脑洞。我觉得你可以在实际代码的运行时中拿一下 vue-router 的实例，钻进去看看最终生成的路由列表，webpack 和 vite 打包的模块导出应该也会找到文件信息的，但是这个我不确定，可以一试。

看每日十分钟

相信自己的感觉