代码重构，没出问题领导没啥好处，出了问题领导背锅

示例有问题， <script setup> 里面不能写  export default

楼主你说这些没用，还不如找机会去大公司

至少我所在的团队，提这些是没人反对你的，最多只是细节上的问题

2 我也确实不能理解，就算 useRequest 这个写法加进来又怎样呢，和 4 是不是自相矛盾。
其他的没办法，凑合干吧，理想和现实的差距。有时候要学会说不，但大部分情况还是多一事不如少一事来的顺心，学会放下

对于问题 1：
要么直接用 option 要么直接用 setup ，目前看这个写法出了麻烦没什么好处，如果是老项目我建议不改，如果是新写，就不要沿用了。

对于问题 2:
对于老项目，重构价值不大的，你领导说的对，不要改，对于新维护，维护频率高的，你可以据理力争改改

对于问题 3:
对于 api 请求我的观点是多少行都无所谓, 应该尽量自动生成，有类型（ PS: 我们项目里面的请求文件目前有 13300 行, 反正 idea 自动折叠无所谓,而且一般不用点进去看）
如果手动写的，确实应该是分模块封装起来用，你领导说的也对，过早的优化是没有必要的

对于问题 4:
按照你们现在这个情况，你领导说的对。因为要执行需要满足下面几个条件：

1. 严格执行 review ，且 review 要求高，必须是交叉 review ，review 不通过不给合并
2. 项目时间安排合理
3. 整个前端所有人达成共识才能执行的
4. 要有对应的规范指南，每个新人进来前两天必须熟读
5. 所有项目的 code style 、lint 规则一致

领导”懒政“而已，做多错多，稳定是第一位的。

如果贵司要求必须写单元测试，并以代码覆盖率作为考核目标，就能解决所有问题。风格再好，代码再漂亮，不写测试最终都会变成一坨大便。

你们领导不注重开发体验，我们公司就很注重开发体验

1 不说了，vue3 主推的就是 hook 写法，用了 vue3 又因循守旧

2 见仁见智了

3 在一开始就应该考虑按照功能模块去拆分。再怎么清晰，放在一个文件也不如拆开来清晰

4 我赞同你领导的说法，任何事情都得考虑成本

事情都有多面性，每个人看问题（比如成本、产出）的角度不同而已。既然他是领导，那就以他为准，而且客观地说，领导说的也都没问题。