关系型数据库的话可以考虑 tidb cloud ，查询量不大的话应该也够用

@MrYELiex https://i.imgur.com/L62ZP7V.png 值得肯定是值得，能在凑点折扣也成嘛，没有就算了

@miserist 教育版就算了没必要白嫖了，都用这么多年了

@alphardex 很漂亮，但是阅读体验太差了，感觉只适合做个展示

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

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

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

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

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

@zictos

我的服务器就在 C 区，整个机器都连不上了。现在都没恢复，还是得靠自己做容灾，切备份节点了

我是用 obisidian 的，可以看我博客：

https://iceprosurface.com/blog/moc/



一般 rebase merge ，merge 只是为了到时候可以快速 revert 而已

附带一个之前我实践生成表格的案例：

https://iceprosurface.com/tool/gpt4o-table-template/

你要先生成一些组件，然后告诉 gpt 你现在有的组件有哪些，然后让他用这些组件去生成会的到比较稳定的结果。

其他几家 ui 稿子自动生成代码的基本都是这么做的

我觉得有两种情况下都能存活很久：

1. 比较纯粹的以自用为目的搭建的话，一般来说都能保留很久的

比如我自己博客： https://iceprosurface.com/ 就是这样从 2016 年开始发布的，到现在应该刚好八年。

自己写的东西基本以后会有目的的去回顾，这样就可以长久的维护，也会产生一些新的思考，最后公开发表出来的博客也是抽取一些自己笔记中的东西，整理以后向外发

2. 有盈利价值的，比如你可以从广告获得收益这样的，也可以长期维护

其他的大多数看到都是写个一两篇以后就销声匿迹了，我反倒是觉得 github.io 是一个好地方，哪怕那天网站没了，或是没法续费了 github.io 大概率还能继续保留你的文章