企业官网建设流程全解析

1. 从“t3code”这个名字说起：它到底指什么

第一次看到“t3code”这个词，很多人会一头雾水。它不像“Python教程”“Vue实战”那样一眼就能看出领域，也不像某个具体框架名那样有官方文档可查。我最初接触到它，是在一个开发者社群里有人发问：“t3code到底是个工具、一个项目代号，还是某种编码规范？”底下回复五花八门，有人说是某个开源脚手架，有人说是团队内部约定的代码前缀，还有人把它和某个技术栈的缩写混为一谈。

先把结论摆在前面：t3code并不是一个广为人知的标准化技术名词，它更像是一个“项目代号”或“内部约定名”。这类名字在实际开发中非常常见——团队立项时随手取一个短、好记、带点技术感的字符串，用来标识一套代码体系、一个工具链组合，或者一个特定业务模块。它的价值不在于名字本身有多响亮，而在于它背后承载的那套可复用的工程实践。

那为什么还要专门写一篇关于它的内容？因为恰恰是这种“非标准命名”的项目，最能反映一线开发者的真实工作状态。你拿到一个叫t3code的东西，没有官方文档，没有社区问答，只有零散的代码片段和同事的口头描述，这时候怎么快速理解它、拆解它、把它变成自己能用的东西，才是真正考验功力的地方。这篇内容就是围绕这个场景展开的：如何从一个模糊的项目名出发，通过代码结构、依赖关系、命名习惯和运行痕迹，反向推导出它的核心逻辑，并整理成可维护、可交接的工程资产。

适合读这篇内容的人有三类：一是刚接手一个“祖传项目”或“内部工具”的开发者，面对的就是类似t3code这种没有文档的代码库；二是团队里负责搭建脚手架或制定规范的人，想看看别人是怎么给项目命名的、怎么组织目录的；三是对工程化感兴趣、想提升代码阅读和逆向分析能力的进阶学习者。不管你用的是哪种语言、哪个技术栈，这套“从名字到架构”的拆解思路都是通用的。

提示：本文不会去考证“t3code”在某个特定社区里的唯一正解，因为这类内部代号本身就没有标准答案。我们关注的是方法论——拿到一个陌生项目名时，如何系统性地摸清它的底细。

2. 拆解一个无名项目的通用路径：先看“痕迹”，再猜“意图”

2.1 从文件命名和目录结构读出项目类型

拿到一个叫t3code的代码库，第一步不是急着看业务逻辑，而是先扫一遍根目录。目录结构就像一个人的穿着打扮，能透露很多信息。如果根目录下同时出现src/、public/、package.json、vite.config.js，那基本可以判断这是一个前端项目，而且大概率用了Vite构建。如果看到pom.xml或build.gradle，那就是Java体系。如果看到go.mod和cmd/、internal/、pkg/这种分层，那就是Go项目的典型布局。

我实际遇到过的一个t3code项目，根目录长这样：

t3code/ ├── apps/ │ ├── web/ │ └── admin/ ├── packages/ │ ├── ui/ │ ├── utils/ │ └── config/ ├── turbo.json ├── package.json └── pnpm-workspace.yaml

看到apps/和packages/并列，再加上turbo.json和pnpm-workspace.yaml，有经验的人立刻就能反应过来：这是一个基于Turborepo的pnpm monorepo。apps/下面放的是可独立部署的应用，packages/下面放的是共享库。这种结构在近几年的前端工程里非常流行，尤其适合中大型团队做多应用复用。

为什么目录结构这么重要？因为它决定了你后续的阅读顺序。如果是monorepo，你就不能只盯着一个src/看，而要先把packages/里的共享包搞清楚，再看各个apps/怎么消费这些包。顺序反了，就会陷入“这个函数从哪来的”这种无休止的跳转里。

2.2 用依赖清单反推技术栈和版本约束

目录结构告诉你“大概是什么”，依赖清单告诉你“具体用什么”。打开package.json，重点看三块：dependencies、devDependencies和scripts。

dependencies里如果出现react、react-dom、next，那就是React体系；出现vue、nuxt，就是Vue体系。但光看框架名不够，还要看版本号。比如"react": "^18.2.0"和"react": "17.0.2"差别很大，前者可以用并发特性、自动批处理，后者不行。再比如"typescript": "^5.0.0"意味着可以用装饰器新语法和const类型参数，而4.x就不行。

devDependencies里藏着构建工具和代码质量工具。看到eslint、prettier、husky、lint-staged这一套，说明项目对代码规范有要求，提交前会自动检查。看到vitest或jest，说明有单元测试。看到playwright或cypress，说明有端到端测试。这些信息决定了你改代码时要注意什么——比如有husky的项目，你提交的代码格式不对是推不上去的。

scripts是最容易被忽略但信息量最大的部分。一个典型的t3code项目可能有这样的脚本：

{ "scripts": { "dev": "turbo run dev", "build": "turbo run build", "lint": "turbo run lint", "test": "turbo run test", "clean": "turbo run clean && rm -rf node_modules" } }

看到turbo run，就知道所有任务都是通过Turborepo编排的，它会根据依赖关系决定执行顺序，还会做缓存。这意味着你单独跑某个子包的dev可能缺少前置依赖，必须用根目录的turbo run dev --filter=web这种带过滤参数的方式。

2.3 通过入口文件定位核心业务流

技术栈摸清之后，就要找“入口”。对于前端应用，入口通常是apps/web/src/main.tsx或apps/web/src/index.ts。打开它，看它引入了什么根组件、注册了什么全局插件、初始化了什么配置。

我习惯用“三遍阅读法”看入口文件：第一遍只看import语句，了解它依赖了哪些外部模块和内部包；第二遍看顶层执行逻辑，比如createApp()、createRoot()、路由注册、状态管理注入；第三遍看条件分支，比如根据环境变量加载不同配置、根据用户权限动态注册路由。

对于后端服务，入口可能是cmd/server/main.go或src/main/java/com/t3code/Application.java。重点看它启动了哪些监听端口、连接了哪些中间件（数据库、缓存、消息队列）、加载了哪些配置文件。这些信息构成了系统的“骨架”，后续所有业务逻辑都是挂在这个骨架上的。

2.4 从命名习惯推断团队约定

一个项目的命名习惯，往往比代码本身更能反映团队的成熟度。比如：

• 组件文件用大驼峰（UserProfile.tsx）还是短横线（user-profile.tsx）？
• 工具函数用动词开头（formatDate、parseQuery）还是名词开头（dateUtils、queryParser）？
• 常量用全大写加下划线（MAX_RETRY_COUNT）还是大驼峰（MaxRetryCount）？
• 类型定义用I前缀（IUser）还是T前缀（TUser）还是无前缀（User）？

这些看似琐碎的细节，其实决定了你写新代码时能不能“融入”现有体系。如果团队用IUser而你写了User，代码审查时大概率会被要求改。更严重的是，如果命名风格混乱，后续维护者会很难判断哪些是接口、哪些是类、哪些是类型别名。

我见过一个t3code项目，它的命名约定非常清晰：所有React组件用大驼峰，所有hooks以use开头，所有工具函数放在packages/utils/src/下并按功能分文件，所有类型定义集中在packages/types/src/下。这种一致性带来的好处是，你看到一个函数名就能猜到它在哪、大概做什么，阅读效率极高。

3. 把t3code跑起来：环境准备中最容易翻车的五个细节

3.1 Node版本与包管理器版本的双重锁定

很多t3code这类monorepo项目会在package.json里写"engines": { "node": ">=18.0.0" }，但这只是建议，不是强制。真正强制的是.nvmrc文件和packageManager字段。

.nvmrc里通常写一个具体版本号，比如18.17.0。如果你用nvm，进入目录后执行nvm use就会自动切换到对应版本。如果没有nvm，就要手动检查node -v是否匹配。版本不匹配的后果可能很隐蔽：比如Node 16不支持某些ES2022语法，构建时才会报错；或者Node 20改变了某些模块解析行为，导致依赖找不到。

packageManager字段是Corepack引入的，写法是"packageManager": "pnpm@8.6.0"。这个字段的作用是：当你在这个项目里执行pnpm install时，Corepack会自动下载并使用指定版本的pnpm，而不是你全局安装的那个版本。为什么要这么设计？因为不同版本的pnpm在依赖提升、锁文件格式、workspace协议支持上都有差异。团队用8.6.0生成的pnpm-lock.yaml，你用7.x去装，可能会产生大量不必要的变更，甚至装出不一样的依赖树。

注意：如果你执行pnpm install时报错说“This project is configured to use pnpm@8.6.0”，说明你的Corepack没启用。执行corepack enable后再试。

3.2 环境变量文件的加载顺序与覆盖规则

t3code项目通常会有多个环境变量文件：.env、.env.local、.env.development、.env.production。它们的加载顺序和优先级是有讲究的。

以Vite为例，加载顺序是：.env→.env.local→.env.[mode]→.env.[mode].local。后面的会覆盖前面的同名变量。local结尾的文件通常被.gitignore忽略，用来放个人本地配置，比如本地的数据库地址、调试开关。

这里最容易翻车的地方是：变量名必须以VITE_开头才能被客户端代码访问。如果你写了一个API_BASE_URL，在代码里用import.meta.env.API_BASE_URL是拿不到的，必须是VITE_API_BASE_URL。这个前缀是Vite的安全机制，防止服务端的敏感变量意外泄露到浏览器。

另一个坑是变量值的类型。环境变量读出来永远是字符串，VITE_PORT=3000拿到的是"3000"而不是3000。如果你直接把它传给需要数字的地方，可能会出问题。我习惯在packages/config里写一个校验层，用zod或类似工具把环境变量解析成正确的类型，启动时就报错，而不是等到运行时才崩。

3.3 依赖安装失败的常见原因与排查顺序

pnpm install失败是新手最常遇到的问题。排查顺序建议如下：

1. 检查网络和镜像源。如果公司内网有私有registry，.npmrc里会配置registry=指向内部地址。如果不在内网，需要改成公共源或公司提供的代理源。
2. 检查Node版本。前面说过，版本不匹配会导致某些包安装失败。
3. 检查锁文件冲突。如果pnpm-lock.yaml和package.json不一致，pnpm会尝试更新锁文件。如果多人同时改了依赖，合并时容易冲突。这时候不要手动改锁文件，而是删掉node_modules和锁文件，重新pnpm install生成。
4. 检查workspace协议。monorepo里子包互相引用通常写成"@t3code/ui": "workspace:*"。如果某个子包的package.json里写的是具体版本号，pnpm会去远程仓库找，找不到就报错。
5. 检查peerDependencies。有些包对React版本有严格要求，如果项目里的React版本不满足，pnpm会警告甚至报错。可以用pnpm why react查看是哪个包引入的。

我踩过最深的坑是：在M1芯片的Mac上装某个包含原生模块的包，因为架构不匹配一直失败。解决办法是在.npmrc里加node-linker=hoisted，或者用Rosetta终端安装。不过现在大部分包都支持arm64了，这个问题越来越少。

3.4 构建脚本的执行顺序与缓存陷阱

Turborepo的核心能力是任务编排和缓存。它根据turbo.json里定义的pipeline来决定执行顺序。一个典型的配置：

{ "pipeline": { "build": { "dependsOn": ["^build"], "outputs": ["dist/**"] }, "dev": { "cache": false }, "lint": {}, "test": { "dependsOn": ["build"] } } }

"dependsOn": ["^build"]的意思是：当前包的build任务，依赖于它所有依赖包的build任务先完成。比如apps/web依赖packages/ui，那么构建apps/web之前会先构建packages/ui。

缓存陷阱在于：Turborepo根据输入文件的哈希值判断是否命中缓存。如果你改了packages/ui的代码但没改它的package.json，哈希值会变，缓存失效，重新构建。但如果你只改了环境变量，而环境变量没有纳入哈希计算，就可能命中旧缓存，导致构建产物不对。解决办法是在turbo.json里配置globalEnv或env字段，把影响构建的环境变量列进去。

3.5 端口占用与代理配置的联动问题

本地开发时，apps/web可能跑在3000端口，apps/admin跑在3001端口，后端API跑在8080端口。前端通过代理把/api请求转发到后端。这个代理配置通常在vite.config.ts里：

server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, rewrite: (path) => path.replace(/^\/api/, '') } } }

常见问题是：后端没启动，前端代理报ECONNREFUSED；或者后端启动了但端口不是8080，代理指向错误；或者changeOrigin没设，导致后端收到的Host头不对，被安全策略拦截。

还有一个隐蔽的坑：如果apps/web和apps/admin同时启动，而它们都配置了代理到同一个后端，后端的CORS策略可能会因为Origin不同而拒绝其中一个。这时候要么在后端配置允许所有本地Origin，要么在前端统一走同一个代理入口。

4. 读懂t3code的代码组织逻辑：monorepo下的包边界与依赖方向

4.1 packages与apps的职责划分原则

在t3code这类monorepo里，packages/和apps/的边界不是随便划的。核心原则是：packages放可复用的、与具体业务无关的代码；apps放具体的业务应用，负责组装packages并提供给最终用户。

举个例子，packages/ui里放的是按钮、输入框、弹窗这些通用组件，它们不知道什么是“用户管理”或“订单列表”。apps/admin里放的是用户管理页面，它引入packages/ui的按钮，再结合自己的业务逻辑和数据请求，组装成完整页面。

这种划分的好处是：当apps/web和apps/admin都需要一个日期选择器时，不需要各写一遍，直接用packages/ui里的就行。改一处，两个应用都生效。坏处是：如果划分不当，packages/ui里混入了业务逻辑，就会导致它被某个应用“绑架”，其他应用想用却用不了。

我见过一个反例：某个t3code项目的packages/ui里有一个UserAvatar组件，它内部直接调用了用户信息的API。这就坏了——packages/ui不应该知道API的存在。正确的做法是：UserAvatar只接收src和name作为props，由使用它的应用去获取用户信息再传进来。

4.2 依赖方向：为什么不能出现循环引用

monorepo里最忌讳的就是循环依赖。比如packages/ui引用了packages/utils，packages/utils又引用了packages/ui，这就形成了环。构建工具在处理循环依赖时，要么报错，要么产生不可预测的行为。

避免循环依赖的方法很简单：画一张依赖关系图，确保它是单向的。通常的层次是：

apps/* → packages/ui → packages/utils → packages/types apps/* → packages/api → packages/utils → packages/types apps/* → packages/config

packages/types在最底层，只包含类型定义，不依赖任何其他包。packages/utils依赖types，提供纯函数工具。packages/ui依赖utils和types，提供组件。packages/api依赖utils和types，提供数据请求封装。apps/*在最上层，可以依赖所有packages。

如果发现某个依赖方向反了，比如packages/utils引用了packages/ui，那就要考虑：是不是这个工具函数其实应该放在ui里？或者是不是应该把公共部分抽到更底层的包？

4.3 共享配置包的设计：eslint、tsconfig、tailwind如何统一

t3code项目通常会有packages/config或packages/eslint-config这样的包，用来存放共享配置。这样做的好处是：所有子包用同一套规则，改一处全局生效。

以TypeScript配置为例，packages/config/tsconfig.base.json里定义基础编译选项：

{ "compilerOptions": { "target": "ES2022", "module": "ESNext", "moduleResolution": "Bundler", "strict": true, "skipLibCheck": true, "esModuleInterop": true, "resolveJsonModule": true, "isolatedModules": true } }

然后apps/web/tsconfig.json里写：

{ "extends": "@t3code/config/tsconfig.base.json", "compilerOptions": { "jsx": "react-jsx", "baseUrl": ".", "paths": { "@/*": ["src/*"] } }, "include": ["src"] }

这样每个应用只需要写自己特有的部分，公共部分继承即可。ESLint配置同理，packages/eslint-config导出不同的配置对象，React项目用@t3code/eslint-config/react，Node项目用@t3code/eslint-config/node。

Tailwind的共享稍微特殊一点，因为Tailwind需要扫描所有使用它的文件。通常的做法是在packages/config/tailwind.base.js里定义主题、插件，然后在各应用的tailwind.config.js里引入并配置content路径：

const base = require('@t3code/config/tailwind.base'); module.exports = { ...base, content: [ './src/**/*.{ts,tsx}', '../../packages/ui/src/**/*.{ts,tsx}' ] };

注意content里必须包含packages/ui的路径，否则UI包里的Tailwind类名不会被生成。

4.4 版本管理与发布：changesets在t3code中的实际用法

如果t3code的packages需要发布到npm供外部使用，就需要版本管理工具。changesets是目前monorepo里最流行的方案。它的工作流程是：

1. 开发者完成一个功能后，执行pnpm changeset，交互式选择哪些包需要发版、是major/minor还是patch，并写一段变更说明。
2. 这个操作会在.changeset/目录下生成一个markdown文件，记录变更信息。
3. 提交代码时把这个文件一起提交。
4. 发布时执行pnpm changeset version，它会根据所有changeset文件自动更新各包的package.json版本号，并生成CHANGELOG。
5. 再执行pnpm changeset publish，把更新后的包发布到npm。

如果t3code只是内部项目、不发布到npm，那changesets可以不用，但版本号仍然建议统一管理。有些团队用pnpm version配合git tag来打版本，也能满足需求。

5. 从t3code的实践里提炼出的五条工程经验

5.1 命名可以随意，但目录结构不能随意

项目代号叫t3code、x7platform还是project-alpha，其实无所谓。但目录结构必须遵循行业共识或团队共识。apps/和packages/的划分、src/下的components/、hooks/、utils/、services/分层，这些是给后来者看的“地图”。地图越标准，别人找路越快。

我建议在项目根目录放一个README.md，用一段话说明目录结构，再用一个表格列出每个目录的职责。比如：

这张表花十分钟就能写好，但能让新成员少走很多弯路。

5.2 环境变量要校验，不要相信“应该没问题”

环境变量是运行时才生效的，构建时无法发现错误。如果VITE_API_BASE_URL没配置，代码里读到的是undefined，请求会发到undefined/api/users，然后报一个莫名其妙的网络错误。与其等到运行时排查，不如在应用启动时做一次校验。

我通常会在packages/config里写一个env.ts：

import { z } from 'zod'; const envSchema = z.object({ VITE_API_BASE_URL: z.string().url(), VITE_APP_TITLE: z.string().min(1), VITE_ENABLE_MOCK: z.enum(['true', 'false']).default('false') }); export const env = envSchema.parse(import.meta.env);

这样启动时如果缺少必要变量或格式不对，会立刻抛出清晰的错误信息，而不是等到用户点击按钮才崩。

5.3 共享包要“薄”，业务包要“厚”

packages/里的包应该尽量薄，只包含最通用的逻辑。一旦某个功能只有一两个应用用，就应该放在应用自己的src/里，而不是抽到packages。过早抽象比不抽象更可怕——你会得到一个充满条件分支的“万能组件”，改一处影响所有应用，谁都不敢动。

判断标准很简单：如果一段代码被三个以上应用使用，且使用方式完全一致，才考虑抽到packages。两个应用用、或者使用方式有差异，就先放在各自应用里，等第三个应用出现时再抽。

5.4 构建缓存能省时间，但配置不对会浪费时间

Turborepo的缓存命中时，构建时间从几分钟降到几秒，体验非常好。但前提是turbo.json配置正确。outputs要写清楚构建产物目录，inputs要包含所有影响构建的文件（默认是包内所有文件，但可以通过inputs精细控制）。如果outputs写错了，缓存恢复时产物不完整，会出现“构建成功但运行报错”的诡异现象。

我习惯在CI环境里加一个步骤：turbo run build --dry=json，输出本次构建的任务图和缓存命中情况。这样能直观看到哪些任务命中了缓存、哪些没有，便于优化。

5.5 文档不是写出来的，是“长”出来的

t3code这类项目最缺的就是文档。但强行写一份大而全的文档，往往没人看、也没人维护。更好的做法是让文档“长”在代码旁边：

• 每个packages的README.md写清楚这个包是干什么的、怎么用、有哪些导出。
• 每个复杂的函数上方写JSDoc，说明参数、返回值、副作用。
• 每个应用根目录的README.md写清楚启动步骤、环境变量、常见问题。
• 用typedoc或vitepress自动生成API文档，减少手写成本。

文档不需要华丽，但需要准确和及时更新。一个过时的文档比没有文档更危险，因为它会误导人。

6. 当t3code需要交接时：如何写一份别人能看懂的README

6.1 交接文档的最小必要信息集

项目交接时，最怕的是“只给代码不给上下文”。一份合格的交接README至少包含以下内容：

• 项目一句话简介：t3code是什么、解决什么问题、给谁用。
• 技术栈清单：语言、框架、构建工具、包管理器、Node版本要求。
• 本地启动步骤：从clone到跑起来的完整命令，包括环境变量配置。
• 目录结构说明：每个顶层目录的职责。
• 核心业务流程：用文字或简单流程图说明主要功能怎么走。
• 常见问题FAQ：安装失败、启动报错、端口冲突等。
• 联系人：遇到问题找谁。

这些内容不需要长篇大论，每项几句话即可，但必须准确。我见过一份交接文档，启动步骤里写的是npm install，但项目实际用的是pnpm，新同事照着做直接报错，浪费了半天时间。

6.2 用脚本代替口头说明

口头交接最大的问题是信息衰减。今天说了十点，明天对方只记得五点。更好的做法是把能自动化的都写成脚本：

• scripts/setup.sh：一键安装依赖、复制环境变量模板、初始化数据库。
• scripts/dev.sh：一键启动所有开发服务。
• scripts/check.sh：一键运行lint、类型检查、单元测试。

脚本本身就是文档，而且是可执行的文档。新同事跑一遍脚本，环境就搭好了，比看十页文档都管用。

6.3 录制一段五分钟的“走查视频”

如果条件允许，录一段屏幕录制，带着看一遍代码结构、跑一遍核心流程、演示一下常见操作。视频的信息密度比文字高，而且能传达文字难以描述的操作细节。五分钟的视频，抵得上一小时的文字阅读。

视频不需要剪辑得很精致，用OBS或系统自带录屏即可。重点是真实——真实地展示你怎么找文件、怎么调试、怎么解决问题。新人看的就是这个过程。

7. 关于t3code，我踩过的三个坑和对应的解法

7.1 子包之间的类型引用找不到声明文件

在monorepo里，apps/web引用packages/ui的组件时，TypeScript需要能找到packages/ui的类型声明。如果packages/ui的package.json里main指向src/index.ts，而types没配置，就会报“找不到模块声明”。

解法有两种：一是让packages/ui先构建，生成dist/index.d.ts，然后main和types都指向dist；二是在开发时用TypeScript的paths映射，直接指向源码：

{ "compilerOptions": { "paths": { "@t3code/ui": ["../../packages/ui/src/index.ts"] } } }

第一种更规范，但每次改UI包都要重新构建；第二种开发体验好，但需要确保构建时也能正确解析。我通常两种都用：开发时用paths指向源码，构建时用dist。

7.2 Turborepo缓存导致环境变量更新不生效

前面提过，Turborepo根据文件哈希判断缓存。如果只改了.env文件，而.env不在inputs里，缓存不会失效，构建产物还是旧的。解法是在turbo.json里配置：

{ "globalDependencies": [".env", ".env.local"], "globalEnv": ["VITE_API_BASE_URL", "NODE_ENV"] }

globalDependencies里的文件变化会导致所有缓存失效，globalEnv里的环境变量变化也会导致缓存失效。这样虽然会降低缓存命中率，但保证了正确性。

7.3 pnpm的严格模式导致幽灵依赖暴露

pnpm默认使用严格模式，只有package.json里声明了的依赖才能被引用。这本来是好事，能避免“幽灵依赖”（用了没声明的包）。但有些老包内部引用了未声明的依赖，在npm下能跑，在pnpm下就报错。

解法是在.npmrc里加：

public-hoist-pattern[]=*eslint* public-hoist-pattern[]=*prettier*

或者更彻底地：

shamefully-hoist=true

shamefully-hoist会把所有依赖提升到根node_modules，行为跟npm一样。但这会失去pnpm严格模式的好处，所以只建议在迁移初期临时使用，后续逐步修复依赖声明。

8. 如果要把t3code扩展成团队标准脚手架，还差什么

8.1 从“能跑”到“好用”的差距

一个t3code项目能跑起来，只完成了30%。剩下的70%包括：统一的代码规范、自动化的代码检查、提交信息规范、CI/CD流水线、错误监控、性能监控、日志收集、灰度发布策略。这些才是团队协作的“基础设施”。

以提交信息规范为例，可以用commitlint + husky，强制提交信息符合Conventional Commits格式（feat:、fix:、chore:等）。这样生成的CHANGELOG是结构化的，版本号也能自动推导。

8.2 模板化：用plop或hygen生成新模块

当团队需要频繁创建新页面、新组件、新API接口时，手动复制粘贴容易出错。可以用plop或hygen定义模板，一条命令生成符合规范的文件结构：

pnpm plop component UserProfile

自动生成UserProfile.tsx、UserProfile.test.tsx、UserProfile.stories.tsx、index.ts，并自动注册到导出文件。这样既保证了结构一致，又减少了重复劳动。

8.3 监控与可观测性：前端也需要“黑匣子”

前端项目同样需要监控。用户白屏了、接口报错了、页面卡顿了，这些如果只靠用户反馈，排查效率极低。接入Sentry或类似工具，能自动捕获JS错误、接口异常、性能指标。再配合sourcemap上传，报错能定位到具体代码行。

日志方面，前端可以用轻量级的日志库，把关键操作和异常上报到日志服务。注意不要记录敏感信息，比如用户密码、token。

9. 写在最后：t3code给我的真正启发

折腾t3code这类项目的过程中，我最大的体会是：工程能力的高低，不体现在你用了多新的框架，而体现在你面对一个陌生代码库时，能不能快速建立认知地图。目录结构、依赖关系、命名习惯、构建配置，这些都是“地图”上的标记。标记越清晰，后来者走得越顺。

另一个体会是：约定大于配置，但约定必须写下来。团队内部约定用apps/和packages/划分，约定环境变量以VITE_开头，约定组件用大驼峰命名——这些约定如果不写进README、不写进lint规则，新人就不知道，时间一长就退化成“每个人按自己习惯来”。写下来、自动化检查，约定才能活下来。

最后分享一个我一直在用的小技巧：每接手一个新项目，先花半小时画一张“依赖关系草图”，用纸笔或白板都行，把apps、packages、外部服务、数据库、缓存之间的关系画出来。这张图不需要精确，但能帮你在脑子里建立全局观。后续看代码时，随时往图上补充细节。等图完整了，项目也就摸透了。