XCFOX

目前的 AI 还是在背答案，没法处理没见过的场景。
我让 Trae + Claude 搭一个 React-Router v7 + tailwind v4 的项目，AI 完全搭不出来。
leetcode 每日一题 中等以上的题 AI 写的代码有几题能过？
这两天爆火的 https://github.com/microsoft/typescript-go 能让 AI 写吗？
什么时候 AI 能写出 typescript-rust ?

我认为 AI 是数学、统计学的终极工具。现在的 AI 学习了海量的代码，并且有非常强的泛化能力。
从能力上看，现在的 AI 大部分是实习生|初级水平，能够识别和理解常见的技术问题，但需要依赖上级工程师（人类）的指导和帮助，问题解决的过程可能较慢，且容易出现反复。

再卷技术还有很大意义吗？有的，兄弟，有的，你需要成为中高级程序员才能更好地指挥 AI 帮你干活。

"90% of code will be written by AI in the next 3 months"
毫无疑问的是，AI 将为行业带来巨大的生产力的提升。现在 AI 给我的感觉是手底下多 3 个 实习生，我可以把重心放到更难的工作上，把脏活累活交给 AI 。

生产力的大幅提升对社会来说无疑是好事。
但对于我们这些从业者来说更多的是焦虑，也许我们会成为新一代无处可去的纺织工人，也许现在的 AI 已经到头了。
或许以后开发成本低了 个人就可以独立开发做出 WPS, Chrome, 黑神话悟空，这未尝不是好事？

可爱捏

接口用的 GraphQL ，代码里会写详细的字段注释，再用框架生成 GraphQL Schema 。前端直接用 GraphQL Schema 生成接口 SDK ，确保端对端类型安全。

可以参考 HeroUI ，给最外面层组件加一个 classNames 属性来传递子组件的 className

https://www.heroui.com/docs/components/card#slots

accessToken 、refreshToken 双 Token 只在分布式|微服务架构下有意义。

考虑我们有用户微服务和订单微服务，我们把用户信息存储在用户微服务，向订单微服务发起请求时需要验证用户有效性：
1. 如果使用单 token 方案，订单微服务接到请求时 需要向用户微服务发起询问来验证用户有效性，在这一步至少需要一次网络通信。
2. 如果使用双 token 方案，向用户微服务发起请求时携带 refreshToken ，向订单微服务发起请求时携带 accessToken ，accessToken 过期时向用户微服务发起请求重写签发 accessToken 。
accessToken 具有以下特性：
· 明文：这允许订单微服务直接从 accessToken 读取用户信息而不必询问用户微服务；
· 具备签名：这允许订单微服务直接验证 accessToken 的有效性而不必询问用户微服务；
· 不可篡改：这使得 accessToken 一经用户微服务签发则在有效期内一直有效，当用户更改密码或其他需要重制登录状态的时候 accessToken 也不受影响，为了满足重制登录状态的需求 accessToken 的有效期一般比较短。
总结一下，双 token 方案使得订单微服务微服务不用向用户微服务发起询问，代价是 accessToken 不可篡改、登录状态难以清除。

回答楼主的问题：
1. refreshToken 只能向用户微服务发起请求，订单微服务无法验证 refreshToken 的有效性；

2. 是的；

3. accessToken 不可篡改，不可延时；

个人看法：双 token 方案带来的「无需向认证服务询问」的特性有一点点优势；但很多场景会有下「踢出用户」的需求，这时候使用双 token 要么等着 accessToken 过期，要么向认证服务发起询问，前者实时性低，后者让损失了 双 token 方案唯一的优势。我的建议是摒弃双 token 方案，使用单 token 存 redis ，认证服务和业务服务都直接从 redis 读取用户状态。

JSX 已经赢了，Vue 支持 JSX ，TypeScript 天然支持 JSX ，后来的前端框架 SolidJS 、Qwik 都直接使用 JSX 作为描述 View 的方案。

在组件化时代，应该以组件为单位做分离。组件内部将逻辑(JS)、视图(HTML)和样式(CSS)写到一起对开发效率有非常大的提升。JSX 允许在 JS 里描述视图，Tailwind 和 css-in-js 允许在 JS 里直接写样式。

接口格式一般听后端的，但是文档一定要写清楚。
最好是加上 OpenAPI/tRPC/GraphQL 确保端对端类型安全，能避免很多接口对接的问题。

React Server Component 在我看来不是一个好的设计，为了解决一个简单问题的问题引入了更多概念和复杂度。

最初 RSC 要解决的简单问题是：在服务端渲染时如何请求数据？
由于 React hooks 令人费解的设计哲学，React 传统组件无法异步。在客户端渲染时，一般通过 `useEffect` 来获取数据。而在服务端渲染时，我们无法使用 `useEffect`，这使得在服务端请求数据（以及其他异步操作）成为了一个问题。顺带一提，vue3(nuxt.js) 就不会面临这个问题，因为 vue3 的组合式 API 没有 React hooks 的一堆限制，并且 setup 是能够异步的。

Next.js(RSC)给出的答案是：设计一个全新的服务端组件，专门用来在服务端发请求。好处是，这个组件可以异步了，坏处是，在这个组件中无法使用 hooks 。
Remix(React-Router-v7)的答案是：Loader 。预先定义好要加载的数据，框架会在数据加载完后将数据注入到组件中。

在我看来 Loader 方案明显比 RSC 更好：

1. 性能更好：Loader 单次加载完成页面所有数据； RSC 每次加载一个组件，加载完父组件的数据，再加载子组件的数据。
2. 更低的心智负担：Loader 只需要提前写好请求，然后方便地通过 useLoaderData 拿到数据； RSC 则引入了额外的服务端组件的概念，在编写时得区分是否为服务端组件，还得到处写 "use client"。

包括新出的 TanStack 也是提倡使用 Loader 方案而不是 RSC 。

参考：
https://react.dev/blog/2020/12/21/data-fetching-with-react-server-components
https://nuxt.com/docs/getting-started/data-fetching
https://remix.run/docs/en/main/discussion/data-flow
https://tanstack.com/router/latest/docs/framework/react/guide/data-loading