如果类型全是一次性生成的，全放一个文件没有任何问题，没必要考虑维护，毕竟是脚本生成的东西，要重构/修改都很简单。
如果无法一次性生成，或者考虑到频繁的单独维护，建议把文件拆开，用文件夹把不同模块的 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 层都可以删了。

@zololiu 某个版本过后一直有广告，但是显示广告要梯子，所以没广告的要么是没更新，要么是没开全局梯子

@krixaar 是两边都开 ipv6 就一定能打洞成功吗？

@MidLinn nat 类型还能改的吗，我晚上试下

@kiduu 我有自建 rustdesk ，延迟太高了，而且服务器带宽太小传个文件都得半天

你想说 gpt 的话，可能到 gpt5 也没法实现，因为文本生成模型本质上是没有逻辑能力的，gpt4 展示出来的逻辑推理能力是一个"短暂的幻觉"，而且并不稳定，不能应用在这方面。但是未来会出现这种 AI 是必定的。

有没有可能，对有些程序员来说这就跟打游戏分享攻略一样，有的人是真的热爱代码，当然你可能无法理解

有个通用的能被轻松搜索到的名字，readme 清晰地介绍了这个项目是什么 做了什么，然后看到你的仓库的人才会考虑去看你的代码。如果大致浏览一遍觉得这个项目能解决自己的某个需求，或者有值得学习的地方，就会考虑点 star 了。star 数其实就是被认同的数量，追求这个我觉得很正常，当然 star 的含水量其实也差异很大，底层库一般 star 都不会太多，因为没那么多人会去研究，而框架类的、应用软件类的会多点，还有各种简易封装库、整合库、教程类项目等等，即使没什么难度也会吸引到 star 。所以你是愿意吸引到哪部分人群呢？不过还是要放宽心，star 基本对面试没有影响，除非你写了个几 k star 的项目。

确定只有一个实现，就没必要接口了

评论离题万里，看到一半都忘了标题是量子计算机

看过了很多 vue3 的 admin 项目，1#这个质量非常高，无论是学习 ts ，了解 vue3 最新的生态(vue3 vite3 unocss 各种 vite 插件等)，学习组件封装等等，都很合适

js 文件本身的加载时间是未知的，所以任何 js 层面的处理都达不到你想要的效果。如果这个误差你能接受，那随便挑一个方法都行。