很明显 AI 是去查百度，然后关键词被广告给污染了

如果优先考虑首屏渲染、打包体积，网站本身没有多少交互，就选 astro 。如果官网未来功能会比较复杂，那就选 nextjs 。

如果是 vue-i18n ，我试过三种做法

一：单文件自定义块
```
<i18n>
{
"zh-CN": {
"a": "xxx"
},
"en-US": {
"a": "yyy"
}
}
</i18n>
```
优点是可以快速搞定，AI 工具一直 Tab 就行了，大部分时间花在看 vue-i18n 文档，缺点是零散在几十几百个 vue 文件里，适合那种特别老的项目，不想额外管理 i18n 文件，且页面和文字几乎不会再改动。

二：json 文件
重构 i18n 确实烦人，但是如果还想正常迭代项目只能重构。将所有中文文本抽离出来，大致分类一下，再让 AI 一次性翻译完英文，然后手动一个个去替换原始文本 t('xxx.yyy')。我建议二层嵌套就行，顶多三层嵌套。

三：ts 文件
事先声明我这属于瞎折腾，用 json 方案就行了。
i18n-ally 和 vue-i18n 在 ts 文件上都有一些坑，搞了好久总算能用了，但是跟 json 方案比差不了多少。
这是我的 i18n-ally 的 vscode 配置文件
"i18n-ally.enabledFrameworks": ["vue"],
"i18n-ally.enabledParsers": ["ts"],
"i18n-ally.parsers.typescript.compilerOptions": {
"moduleResolution": "node"
}
这样就能正常识别 ts 文件

这是我的 i18n/index.ts 文件
import zhCN from './locales/zh-CN'
import enUS from './locales/en-US'

const messages: Record<I18n.Language, I18n.LocaleMessage> = {
'zh-CN': zhCN,
'en-US': enUS,
}

const i18n = createI18n({
locale: getStorage(StorageKeyEnum.language, 'zh-CN'),
fallbackLocale: 'en',
messages,
legacy: false,
})

export function setupI18n(app: App) {
app.use(i18n)
}

export function setLocale(locale: I18n.Language) {
i18n.global.locale.value = locale
}

export const t = i18n.global.t

LocaleMessage 是我的翻译文本类型
大概这样
type LocaleMessage = {
icon: {
...
}
route: {
...
}
tab: {
...
}
table: {
...
}
}

然后可以递归得到所有 key 的联合类型
type GetI18nKey<T, K extends keyof T = keyof T> =
K extends string ?
T[K] extends Record<string, unknown> ?
`${K}.${GetI18nKey<T[K]>}`
: K
: never

type I18nKey = GetI18nKey<LocaleMessage>

type RouteKey = GetI18nKey<LocaleMessage, 'route'>
type TableKey = GetI18nKey<LocaleMessage, 'table'>

在你需要硬编码比如路由元信息等地方用 I18nKey 类型进行限定就能完全消除硬编码
https://i.imgur.com/SUHCLUG.jpeg
https://i.imgur.com/PeuE0GI.jpeg

全用 post 。
现实是复杂的，RESTful 的表达能力不足以覆盖所有 case ，强行使用统一约定会让一些简单的东西变得难以理解。
2#说 `全用 POST ，那么安全审核无法直接区分这个 POST 是“新增”还是“删除”，只能靠解析 URL 或 Body ，这样更复杂印象性能且容易漏。`
为什么要区分是新增还是删除，而且一个接口本来就可以删除一些 A ，新增一些 B ，修改一些 C 。
真正的安全策略应该基于权限规则和业务逻辑，不应该简单地基于约定式的 Method ，它本质上和 /add /edit /del /info /page 一模一样，能严格遵守 RESTful 标准的人，同样能遵守自定义的语义要求。
我一直觉得接口的语义化完全没必要，一个硬编码玩出花来有什么意义，只要把代码给组织好就足够了。

语言的语法是用来增强表达的能力，你这个设计不太好，增加了阅读/编写的复杂度，但是收益无法抵消额外开销，在我看来是负优化，想在 java 里搞奇技淫巧的应该直接转 kotlin/scala ，别指望能在垃圾语言上屎上雕花，只能屎上雕屎。
命名参数这玩意，是为了把参数从水平转成垂直，就像浏览器的普通标签页 vs 垂直标签页，语法上想实现这种功能，一定要支持默认参数/可选参数，所以 java 只能洗洗睡了。
而且命名参数也不是最好的设计，js 不支持命名参数，但是 es6 的参数解构远比命名参数好用。

@llej node 实现 ts 类型严谨具体是指什么，是前端调用了不存在的接口就类型报错吗，调用对应接口拿到入参类型和返回类型？
你可以看一下 tPRC ，或者 hono 的 RPC ，虽然重构的工作量可能会很大。
hono 的 RPC 是后端导出一个或者多个路由实例类型给前端使用，客户端底层是基于 fetch 实现，前端调用这个接口就像直接调用后端接口方法一样，带来的收益是无需专门为接口类型定义一堆的类型到处混乱地引用，因为接口本身已经有类型了。
在你这个场景下，可以每个模块都导出一个路由实例，最后在基座包组装所有路由，再把类型导入到前端，最终得到包含所有接口路径、入参、返回类型的一个 http 客户端，前端只需要调用这个客户端就行，不存在的接口或者入参不对都会报错。你也可以让一部分路由只给同个顶级包下的前端模块引用，这样就实现了或许会用到的接口 public/private 修饰功能。

@williamx #84
如果接受了“谁能力强谁改”这种做法，那整个团队的平均水平就会由水平最差的那个人决定，这也同时严重影响了开发舒适度和个人前景。
正确做法是让能力不足的人滚蛋，换个能正常写代码的人进来。
说实话这就他妈一行小学生水平破代码的事，写不出来的还他妈能叫程序员？
data.map(({ x, ...rest }) => ({ ...rest, x: x.join(',') }))
就算是树结构也就 10 行的事。
type Data = { x: number[]; children?: Data[] }
type Data1 = { x: string; children?: Data1[] }
const res: Data[] = []
const recursive = (nodes: Data[]): Data1[] =>
nodes.map(({ x, children, ...rest }) => ({
...rest,
x: x.join(','),
...(children && { children: recursive(children) }),
}))
const data = recursive(res)
而且这跟简单还是困难无关，这就是前端必须要做的事情，写 100 行也好 1000 行也好就应该在前端处理。那个用字符串绑定的弱智组件也应该换个给地球人使用的正常组件。

@dssxzuxc #27 但是->或者

@Greendays #22 你说得对，可能后端不知道是偷懒还是设计上的限制依然需要所有 tags ，然后卡住了。试了几个 tag 数量很多的 repo ，加载都非常慢，而且每点一页都要等很久，好奇是写了什么屎山代码，但是不得不这么做没办法实现真正的分页，只能做假分页。

@Greendays #18 因为 tag 就没必要做分页啊，看到这仓库之前我想不出 tag 要加分页的理由，看完后也没必要，而是应该加一个 tag 数量上限提前限制。虽然所有 list 都可以用 page 解决，但不代表 page 是最佳实践，这个场景不管是产品经理还是程序员都不可能会支持 page

报警并不一定需要做笔录，除非是直接涉事人员，或者案情达到立案标准。这种事一般是喊来双方家长当场协调清楚，后面民警会跟进，报警人问几句话就可以走了，提前走也没问题，顶多有个电话回访，报警是义务，并不是责任。

奇怪，明明有 TypeScript 节点，为什么这个帖子会出现在 Node.js 节点？

一本我不太喜欢的小说，一直记得序章有这么一句话，如果人生能够重来，我大概还是这样。
回首人生确实浪费了不少时间，选了一些错误的路，但再来一次也不会做其他选择，只是会做得更好。
时间就是用来浪费的，你不在某个地方浪费生命，也会在别处浪费生命。