dssxzuxc

@pkoukk #23 我用了两个月就受不了了，散光严重很多，羡慕能长时间用暗黑模式不受影响的人

如果类型全是一次性生成的，全放一个文件没有任何问题，没必要考虑维护，毕竟是脚本生成的东西，要重构/修改都很简单。
如果无法一次性生成，或者考虑到频繁的单独维护，建议把文件拆开，用文件夹把不同模块的 api 分开
-- A
|-- index.ts
|-- type.d.ts
-- B
|-- index.ts
|-- type.d.ts
-- C
|-- index.ts
|-- type.d.ts

楼上说 d.ts 不是这样用的，确实有一定道理，之前接触到的项目接口类型定义都是写.ts 里的，但是如果不是太多人协作的话我还是强烈建议用 d.ts 方式，省了无数麻烦，只要 namespace 规划合理就行

A 表 B 字段 joinC 表 D 字段，select * from A 两个字段的排序规则需要一致，所以最好统一全部数据库字段的排序规则，有特殊需求的字段再另外调整，同时注意这个字段和其它字段 join 时会不会出问题。
另外可以配置成不同的排序规则也允许 join ，但是一般不建议这么做，或者查询时指定成相同的排序规则，但是本来就屎山的长 sql 会更加恶心

@vczyh 我正在看 nutui ，感觉还是 taro 好，uniapp 体验下来真不行

@wolfan 原生不考虑，我还得再看一遍 qq 小程序的文档，然后重复写两遍

win11 记事本我也遇到一个很扯淡的问题，记事本右上角直接关闭，下次点别的记事本会把上一个关闭过的记事本也一起打开了，通过标签页关闭就没事，真的服了

感谢楼主

@sduoduo233 2023 年了，我觉得很不正常。

把垃圾放一楼还是二楼的问题，不可复用的代码，放哪都行，可复用或者可能复用的，放 service 。代码一律放 service 的多半是常年这么写习惯了或者有强迫症，实际上放 controller 当然没问题。如果是我自己的项目，我用 mybatisplus ，不可复用的全写 controller 了，并且只使用 service ，mapper 都用不到，第一眼就能看到实际代码。如果是微服务并且几乎全是单表查询，mapper 层都可以删了。