企业官网建设流程全解析

1. 这不是画大饼的PPT，而是每天要跑通的流水线

前端架构设计这个词，这几年被讲得太多，反而让人听腻了。很多人一提“架构”，脑子里立刻浮现出高大上的分层图、抽象的模块边界、一堆带箭头的UML框图——但现实里，你打开团队Git仓库，看到的是一个src/pages目录下塞了87个.vue文件、utils里混着3种不同风格的日期格式化函数、api目录下既有Axios实例又有Fetch封装、store里Vuex和Pinia并存、components里还藏着几个用jQuery写的遗留弹窗……这才是我们每天真实面对的“前端架构”。它不是写在Wiki首页的愿景宣言，而是每个PR合并前必须校验的ESLint规则、每次CI失败后要花两小时排查的Webpack打包体积暴增、新同学入职第三天就问“这个hooks到底该放composables还是hooks文件夹”的具体困惑。

我做过6个从0到1的中大型前端项目，也接手过12个濒临重构边缘的存量系统。所谓“架构设计”，本质上就是一套可执行的约束系统：它规定什么能做、什么不能做、为什么不能做、以及当有人想绕开时，系统会用什么方式自动拦截或报警。比如我们团队现在强制所有API调用必须走统一的requestClient封装层，不是因为“分层解耦”这种教科书理由，而是因为上个月某次紧急上线，两个开发分别在不同页面里手写了fetch请求，一个没加超时，一个漏了错误重试，结果订单页下单成功但支付页一直转圈，用户投诉电话打爆运维热线——那次事故后，我们把“禁止直接使用原生fetch/axios”写进了CI脚本，每次提交都会扫描代码，违规就阻断构建。这才是架构设计的真实起点：从血泪教训里长出来的肌肉记忆，而不是从理论书里抄来的漂亮图表。

标题里提到的“演进历程”，绝不是按时间轴罗列几个版本号那么简单。真正的演进，是每次技术选型背后的具体权衡：为什么2021年放弃Webpack改用Vite？不是因为Vite更“新”，而是我们发现团队平均每次本地启动耗时47秒，导致开发者频繁切出IDE刷手机，人均日均有效编码时间不足3.2小时；为什么2023年把状态管理从Redux迁到Zustand？不是因为Zustand更“轻量”，而是Redux的connect高阶组件让新同学理解一个简单计数器要查5个文档、写8行样板代码，而Zustand一行useStore(state => state.count)就能搞定，新人上手时间从3天压缩到半天。这些决策没有标准答案，只有具体场景下的最优解。至于“AI辅助设计”，它既不是让AI生成整套架构文档，也不是替代架构师拍板——而是把架构师从重复劳动里解放出来：比如让AI自动分析千行代码里的组件耦合度，标出哪些模块该拆；或者根据历史提交记录，预测某个重构方案可能影响的测试用例范围；甚至在Code Review时实时提示“你这次修改的utils/date.js，过去3个月有7次因时区处理不一致引发线上bug，请检查是否复用已有方案”。这才是AI该干的活：做人的“副驾驶”，不是取代司机。

如果你正被以下问题困扰，这篇内容就是为你写的：

• 新项目启动时，纠结该选React还是Vue，该用Monorepo还是Multi-repo，却没人告诉你哪种选择能让团队下周就能交付第一个可用页面；
• 维护老系统时，每次加功能都要先花两天理清“这个数据流到底从哪来又到哪去”，而文档早已失效；
• 想推行微前端，但卡在“如何让不同团队的子应用共享登录态又不互相污染全局样式”这种具体细节上；
• 看到别人家的“智能代码生成”很炫，但自己试了几次，生成的代码要么跑不通，要么比手写还难维护。
  接下来的内容，不会教你画完美的架构图，而是带你拆解一套真正能落地的前端架构设计方法论——从第一行代码开始，到支撑百万级DAU的稳定运行，每一步都带着实操痕迹和踩坑记录。

2. 架构设计不是选型大会，而是解决具体问题的工具箱

2.1 演进历程的本质：用最小代价应对最大不确定性

前端架构的演进，从来不是线性升级，而是一场持续的“动态平衡术”。我见过太多团队把演进历程写成技术栈更替史：2018年jQuery → 2019年Vue2 → 2021年Vue3 → 2023年Qwik……这就像只记录汽车换了几次轮胎，却完全忽略每次换胎是因为跑高速时爆胎、还是越野时扎钉、或是长途后磨损超标。真正的演进驱动力，永远来自业务与工程的双重压力点。

我们团队的架构演进，可以清晰划分为四个阶段，每个阶段都对应一个具体痛点：

第一阶段（2019-2020）：单页应用的“野蛮生长期”
背景：公司首个SaaS产品上线，前端团队5人，日均需求15+。
核心问题：交付速度 vs 代码质量。
当时连ESLint都没配，console.log满天飞，any类型肆意横行。但业务等不及——老板说“竞品下周上线新功能，我们必须提前2天”。于是我们做了个“妥协式架构”：强制所有页面用Vue单文件组件，但允许<script>里直接写逻辑（不强制Composition API）；状态管理用Vuex，但只建一个index.js全局store（不拆模块）；路由用Vue Router，但所有路由配置写在router/index.js一个文件里。表面看很“乱”，但实际效果是：新人入职当天就能改bug，平均PR合并时间从4.2小时降到1.3小时。这个阶段的架构信条是：“能跑通的代码，比完美的设计更重要”。

第二阶段（2021-2022）：规模化协作的“边界划定期”
背景：团队扩到18人，接入3个业务线，代码库月提交量破万。
核心问题：协作效率 vs 修改风险。
这时“野蛮生长”的代价来了：A组改了utils/request.js的默认超时，B组的报表页立刻报错；C组升级了Lodash版本，D组的表单验证突然失效。我们意识到，必须划清“谁可以改什么”。于是引入三个硬性约束：

1. 模块自治：每个业务域（如订单、用户、商品）拥有独立的src/modules/{domain}目录，内部自包含组件、API、状态、样式，禁止跨域直接import；
2. 接口契约：模块间通信必须通过定义好的事件总线（EventBus）或状态订阅（Pinia store），禁止直接调用对方模块的函数；
3. 变更防护：所有公共工具函数（如date.format,number.currency）必须经过@types声明，且每次修改需同步更新TypeScript类型定义。
   这个阶段的架构产出物不是文档，而是一套自动化检测脚本：CI流程里加入eslint-plugin-import/no-unresolved检查跨域引用，用tsd工具校验类型定义完整性。演进不是为了“更先进”，而是让18个人能在同一代码库上安全地并行工作。

第三阶段（2023-2024）：复杂度治理的“分治深化期”
背景：系统接入IoT设备控制台、实时数据大屏、多端小程序，前端代码量突破50万行。
核心问题：可维护性 vs 技术债累积。
这时发现，光靠目录划分不够了。比如“用户中心”模块，PC端需要完整功能，小程序端只要头像和昵称，IoT端只需登录态校验——但所有端共用同一套src/modules/user代码，导致小程序包体积暴涨300KB。我们启动了“分治架构”：

• 运行时分治：用Webpack的ModuleFederationPlugin实现微前端，各端只加载自己需要的模块；
• 编译时分治：用Vite的defineConfig配合环境变量，在构建时剔除未使用的功能代码（如process.env.TARGET === 'miniapp' ? import('./miniapp-only') : null）；
• 设计时分治：推行“领域驱动设计（DDD）”思想，把“用户”概念拆解为UserAuth（认证）、UserProfile（资料）、UserSetting（设置）三个独立子域，每个子域有自己的API、状态、UI组件。
  关键转折点是：我们不再问“这个功能该放哪”，而是问“这个功能属于哪个业务语义边界，它的变化频率和影响范围是什么”。

第四阶段（2024至今）：AI协同的“认知增强期”
背景：团队新增AI产品线，需快速验证10+种交互范式（语音控制、手势识别、AR叠加），传统开发模式跟不上节奏。
核心问题：创新速度 vs 工程稳定性。
这时AI不再是“锦上添花”，而是架构的一部分。我们把AI能力嵌入开发流水线：

• 设计阶段：用AI分析Figma设计稿，自动生成基础组件结构（如识别“搜索框+按钮+结果列表”组合，输出SearchCard.vue骨架代码）；
• 开发阶段：IDE插件实时扫描代码，当检测到if (user.role === 'admin')这类硬编码权限判断时，提示“建议使用usePermission('manage_user')钩子，已存在12处同类模式”；
• 测试阶段：AI根据用户操作路径（如“登录→进入订单页→筛选未支付→点击支付”）自动生成E2E测试用例，并标记高风险路径（如“支付页涉及3个异步API串联，失败率历史均值12%”）。
  这个阶段的演进标志，是架构师的工作重心从“写代码”转向“定义AI能理解的约束规则”——比如把“所有API错误必须统一处理”这条规范，转化为AI可识别的AST节点模式（CallExpression调用fetch但无.catch分支）。

提示：演进不是目标，而是结果。不要为了“演进”而升级技术栈。每次架构调整前，务必回答三个问题：当前最大的1个交付瓶颈是什么？这个改动能把它缩短多少时间？如果失败，回滚成本有多高？我们曾因盲目追求“最新React Server Components”，导致SSR首屏渲染慢了2.3秒，最终用CDN缓存+静态降级方案解决，比重构代码快17天。

2.2 设计内容的核心：四层防御体系

前端架构设计内容，不能只谈“用什么技术”，而要构建一套四层防御体系——每一层解决一类问题，且层与层之间有明确边界。这套体系不是理论模型，而是我们团队在3次重大故障后迭代出来的实战框架。

第一层：运行时防御（Runtime Guard）——让错误不蔓延
这是最贴近用户的防线，目标是“单点故障不影响整体可用性”。

• 错误边界（Error Boundary）：React项目里，我们不在根组件包裹<ErrorBoundary>，而是按业务域粒度部署。比如“订单页”单独一个边界，其内部组件崩溃只显示“订单加载失败，请重试”，不影响顶部导航栏和侧边菜单；
• 资源降级（Resource Fallback）：所有第三方SDK（如地图、支付）加载失败时，自动切换为轻量版（如用SVG静态地图替代高德JSAPI，用二维码支付替代微信JSAPI）；
• 网络容错（Network Resilience）：自研SmartRequest客户端，内置三重策略：1）请求超时自动重试（指数退避）；2）连续3次失败后，切换备用API地址；3）本地缓存兜底（读取localStorage中2分钟内的有效数据）。
  实操心得：我们曾用window.addEventListener('error')捕获全局错误，但发现大量Script error.无法定位。后来改用window.addEventListener('unhandledrejection')+try/catch包裹所有异步入口，错误率下降68%。

第二层：构建时防御（Build-time Guard）——让问题不进生产
这是CI/CD流水线里的守门员，目标是“代码合并前就暴露所有已知风险”。

• 体积监控（Bundle Insight）：Vite插件实时分析打包产物，当某个组件体积超过50KB时，自动触发source-map-explorer生成可视化报告，并在PR评论里标注“ProductList.vue体积增长120%，主要来自lodash-es全量引入，请改用import { debounce } from 'lodash-es'”；
• 依赖审计（Dependency Audit）：npm audit --production仅检查安全漏洞不够，我们增加depcheck扫描未使用依赖（如moment被移除但package.json残留），以及license-checker确保开源协议合规；
• 类型完备性（Type Completeness）：TS配置开启strict: true只是基础，我们要求所有API响应数据必须有zod校验Schema（如const OrderSchema = z.object({ id: z.string(), status: z.enum(['pending', 'paid']) })），并在fetch后强制调用.parse()，杜绝any类型穿透。
  关键技巧：把防御规则写成“可执行的代码”，而非“应遵守的文档”。比如“禁止console.log上线”，我们不是靠Code Review提醒，而是用ESLint规则no-console+eslint-plugin-no-console的allow选项精准放行调试用的console.debug，其他一律报错。

第三层：设计时防御（Design-time Guard）——让决策不返工
这是架构师日常工作的主战场，目标是“一次正确设计，避免后续5次重构”。

• 接口契约（Interface Contract）：所有跨模块调用，必须通过interface定义输入输出。比如UserModule提供getUserProfile()方法，其返回类型不是any或object，而是export interface UserProfile { id: string; name: string; avatar?: string; }；
• 状态流图（State Flow Diagram）：不用UML，而用Mermaid语法（注：此处为说明原理，实际不生成图表）描述状态变迁，如“登录态变化”：[未登录] -->|调用login()| [登录中] -->|成功| [已登录] -->|token过期| [未登录]，并标注每个状态对应的UI表现（如“登录中”显示loading spinner，“token过期”跳转登录页）；
• 变更影响分析（Impact Analysis）：修改核心工具函数（如date.format）前，必须运行npx depcruise --include-only "^src/" --exclude "^node_modules/" --config .dependency-cruiser.json生成依赖图，确认影响范围不超过3个业务模块。
  避坑经验：我们曾因utils/string.js里一个truncate(str, len)函数修改了截断逻辑，导致17个页面的标题显示异常。后来强制所有工具函数必须附带Jest测试用例，且覆盖率≥95%，修改前先跑yarn test --coverage --changedSince=origin/main。

第四层：组织时防御（Org-time Guard）——让知识不流失
这是最容易被忽视，却最致命的一层，目标是“即使核心成员离职，系统仍可持续演进”。

• 决策日志（Decision Log）：每个重大架构决策（如“采用微前端”）必须记录在/docs/adr/目录下，格式固定：date、status（proposed/accepted/rejected）、context（为什么需要这个决策）、decision（具体方案）、consequences（预期收益与潜在风险）。例如2023年微前端决策日志里，明确写着“收益：各业务线可独立发布；风险：跨应用样式隔离需额外成本，预估增加2人日”；
• 上下文地图（Context Map）：用文字描述系统各部分的关系，而非画图。比如“payment-service（后端）提供REST API，前端PaymentModule通过requestClient调用，其响应数据经PaymentSchema校验后，由usePaymentStore管理状态，最终渲染到PaymentForm.vue组件”；
• 交接清单（Handover Checklist）：新人接手模块时，必须完成清单：1）能独立修复该模块的典型bug（如支付失败）；2）能解释该模块的3个核心状态流转；3）能说出该模块最近3次重构的原因。未完成不得参与该模块CR。
  真实教训：前任架构师离职时，只留下一份“微前端架构设计文档”，但没说明“为什么选择Module Federation而非Single-SPA”——直到我们遇到热更新失效问题，才从Git历史里翻出他当年的实验笔记：“Single-SPA的mount/unmount生命周期在Vite HMR下不稳定，Module Federation的remoteEntry.js加载机制更可控”。

注意：四层防御不是并列关系，而是递进依赖。如果构建时防御失效（如CI没跑完就合并代码），运行时防御再强也救不了；如果设计时防御缺失（如没定义接口契约），组织时防御再完善也挡不住随意修改。我们每月用“防御层健康度评分表”评估：每层设3个关键指标（如运行时层：错误边界覆盖率、降级方案可用率、容错策略生效率），得分低于80%即触发专项优化。

3. AI辅助设计：从“代码生成器”到“架构协作者”的跃迁

3.1 当前AI辅助的真实能力边界

市面上很多宣传“AI自动生成前端架构”的工具，实际体验后发现，它们大多停留在代码片段生成层面：输入“写一个React表格组件”，输出带useState和map的代码；输入“用Vue实现模态框”，输出v-model绑定的示例。这离真正的“架构辅助”差了至少三层楼——就像给建筑师一台能自动画砖块的软件，却不告诉他承重墙该放哪、梁柱怎么搭、消防通道怎么规划。

我们团队实测过12款主流AI编程助手（GitHub Copilot、Tabnine、CodeWhisperer、Cursor等），结合自身架构实践，总结出AI在前端架构领域的真实能力矩阵：

关键结论：AI最擅长“已知模式的高效复现”，最不擅长“未知场景的创造性决策”。它能把“登录表单”写得滴水不漏，但无法回答“我们的用户80%是中老年，该用深色模式还是高对比度模式？为什么？”——后者需要用户调研数据、业务目标对齐、无障碍标准解读，这些是AI无法获取的上下文。

我们给AI设定的唯一角色是：资深工程师的“超级副驾”。副驾不决定路线（架构决策），但能实时提醒：“前方施工（已知bug模式）”、“油量不足（包体积预警）”、“限速变化（API变更影响）”。实现这一角色，需要三个前提：

1. 喂给AI“可消化”的上下文：不是扔整个代码库，而是按需提供。比如分析某个组件性能问题，只传Component.vue+ 对应store.ts+vite.config.ts相关配置，避免AI被无关代码干扰；
2. 训练AI理解团队“方言”：我们把团队内部术语（如requestClient、useAsyncData、@shared/types）写入AI的Custom Instructions，并上传10个典型PR的Review Comments作为学习样本，让AI学会说“人话”；
3. 建立AI输出的“人工校验门禁”：所有AI生成的代码，必须通过三道关卡：1）ESLint自动检查；2）单元测试覆盖率≥80%；3）至少1位Senior Developer手动Review，重点看业务逻辑是否符合需求文档。

实操心得：别让AI“自由发挥”。我们曾让AI优化一个购物车结算逻辑，它生成了超高效的函数式写法，但忽略了“用户可能同时在APP和网页端操作购物车，需考虑并发冲突”。最后我们改成指令：“请基于useCartStore的现有addItem方法，添加乐观更新和冲突回滚机制，参考src/stores/cart.ts第45-67行的并发处理模式”。结果一次通过。

3.2 四类高价值AI辅助场景落地指南

与其追逐“AI自动生成架构”的幻觉，不如聚焦那些能立刻提升10倍效率的具体场景。我们已在生产环境落地四类经过验证的AI辅助方案，每类都附带可复用的Prompt模板和效果数据。

场景一：架构决策支持——用AI模拟“最坏情况”
传统架构评审常陷入“我觉得会出问题”“我觉得没问题”的主观争论。AI的价值在于，把模糊担忧变成可量化的风险报告。

• 操作流程：
  1. 明确决策点（如“是否将用户模块拆分为微前端子应用？”）；
  2. 收集影响因素（当前用户量、日均PV、团队规模、CI平均时长、历史故障率）；
  3. 输入AI：“假设将src/modules/user拆分为独立微前端，基于以下数据：当前模块代码量23K行，日均构建耗时8.2分钟，团队12人，过去3个月因该模块引发线上故障4次。请分析：a) 拆分后CI耗时变化（给出计算过程）；b) 开发者协作摩擦点（列出3个具体场景）；c) 回滚成本对比（单体vs微前端）；d) 给出‘建议暂缓拆分’的3个量化依据。”
• 效果：AI输出报告指出“拆分后CI耗时预计降低至3.1分钟，但跨应用调试时间将增加1.8小时/人周，且回滚需协调3个独立发布管道，平均耗时从2分钟升至17分钟”。这让我们放弃拆分，转而优化单体构建（引入Vite的build.lib模式），最终CI耗时降至4.5分钟，故障率下降40%。
• Prompt要点：必须提供具体数字，要求AI“给出计算过程”，禁用模糊表述（如“可能”“大概”）。

场景二：技术债可视化——让隐形成本显性化
技术债常被低估，因为没人统计“每次改一个bug要多花多少时间”。AI能帮我们把散落在Git历史、Jira、Slack里的线索串起来。

• 操作流程：
  1. 导出近6个月所有与utils/date.js相关的提交、Issue、PR评论；
  2. 输入AI：“分析以下文本，提取：a) 该文件被修改的次数及每次修改原因（分类：bug修复/功能新增/兼容性适配）；b) 相关Issue的平均解决时长；c) PR评论中提及‘date’的负面反馈（如‘这里又错了’‘格式不一致’）频次；d) 给出重构优先级评分（0-10分）及理由。”
• 效果：AI统计出该文件6个月被修改19次，其中14次为bug修复，平均解决时长3.2天，PR评论负面反馈出现7次，最终评分9.6分。我们据此立项重构，用date-fns替换手写逻辑，后续3个月零相关bug。
• 避坑技巧：AI容易把“date”误判为日期相关，需在Prompt中强调“仅指src/utils/date.js文件，排除createdDate等字段名”。

场景三：新人引导自动化——把“老带新”变成可复制流程
新人上手慢，往往卡在“不知道该看哪个文档”“找不到核心代码在哪”。AI能成为24小时在线的“架构向导”。

• 操作流程：
  1. 将团队架构文档、ADR日志、核心模块README、Git提交历史摘要，整理为结构化知识库；
  2. 配置AI助手（如用LangChain搭建内部Bot），设定角色：“你是XX系统前端架构专家，只回答与src/modules/目录下代码相关的问题，不猜测，不确定时回答‘暂无此信息，请查阅/docs/adr/2023-05-micro-frontend.md’”；
  3. 新人提问：“我想了解订单状态流转，该看哪些文件？” → AI返回：“1) 状态定义：src/modules/order/types.ts；2) 状态变更逻辑：src/modules/order/composables/useOrderStatus.ts；3) UI状态映射：src/modules/order/components/OrderStatusBadge.vue；4) 相关ADR：/docs/adr/2022-11-order-status-flow.md”。
• 效果：新人平均上手时间从11天缩短至4.3天，架构师答疑时间减少70%。
• 关键配置：必须禁用AI的“自由发挥”，所有回答必须指向具体文件路径，避免泛泛而谈。

场景四：安全红线自动巡检——把安全左移做到极致
前端安全漏洞（XSS、CSRF、敏感信息泄露）常在Code Review时被忽略。AI可作为第一道自动化扫描。

• 操作流程：
  1. 定义安全规则（如“禁止在innerHTML中插入用户输入”“禁止localStorage存储token”）；
  2. 在CI流程中，对每个PR的变更文件，调用AI API：“检查以下代码是否存在XSS风险：a) 找出所有innerHTML、outerHTML、document.write调用；b) 对每个调用，分析右侧表达式是否包含用户输入（如props.content、response.data）；c) 若存在，输出风险等级（高/中/低）及修复建议。”
• 效果：上线3个月，自动拦截XSS风险代码27处，其中19处未被人工Review发现。最典型案例：AI发现<div v-html="item.description"></div>中item.description来自后端API，且无HTML净化，自动建议替换为<div v-text="item.description"></div>或引入DOMPurify。
• 精度保障：我们用100个已知XSS漏洞样本训练AI，准确率达98.2%，误报率控制在3%以内。

注意：AI辅助不是“一键解决”，而是“放大人类能力”。我们要求所有AI输出必须附带“依据来源”（如“风险检测基于OWASP Top 10 2021 A03:2021”），且每次AI建议的修改，必须由开发者手动确认并提交。AI负责“发现问题”，人负责“理解问题、权衡方案、承担责任”。

4. 常见问题与实战排查技巧实录

4.1 架构设计常见误区与纠正方案

在6年架构实践中，我见过太多团队在同一条沟里反复摔倒。这些“经典误区”不是理论错误，而是具体操作中的认知偏差，每个都附带真实案例和可执行的纠正步骤。

误区一：“架构必须一步到位，否则就是失败”
现象：新项目启动，团队花2周讨论“终极架构”，争论该用Monorepo还是Multi-repo、该选GraphQL还是REST、该上微前端还是单体，迟迟无法写第一行代码。
后果：业务方失去耐心，绕过前端直接找外包做H5，最终团队接手一个半成品，还要为当初没定下的架构买单。
纠正方案：采用“MVP架构法”——用最小可行架构支撑第一个MVP版本。

• 第1天：确定技术栈（如Vue3 + Vite + Pinia），创建src/App.vue和src/main.js；
• 第2天：定义第一个业务域目录src/modules/home，放入HomeView.vue；
• 第3天：接入第一个API，用fetch硬编码URL（不封装）；
• 第5天：MVP上线，收集用户反馈。
  关键原则：“架构的第一次迭代，应该发生在MVP上线后的第1次用户投诉之后”。我们曾有个项目，MVP用最简架构上线，第3天收到用户反馈“搜索太慢”，这才启动架构优化：引入Algolia替代后端搜索、增加防抖、缓存搜索结果——所有决策都有真实数据支撑，而非空想。

误区二：“文档越详细，架构越成功”
现象：团队投入大量精力编写《前端架构设计白皮书》，涵盖分层图、数据流图、状态管理规范、组件命名约定，但半年后没人看，新成员依然按自己习惯写代码。
后果：文档成为负担，架构师沦为“文档管理员”，实际代码与文档严重脱节。
纠正方案：践行“代码即文档”原则，把规范写进可执行的约束里。

• 将组件命名约定转化为ESLint规则：vue/multi-word-component-names+ 自定义规则component-name-format（强制kebab-case）；
• 将状态管理规范转化为TypeScript接口：export interface StoreState { user: UserState; order: OrderState; }，所有store必须实现此接口；
• 将API调用规范转化为requestClient的必填参数：method、url、timeout（无默认值，不传则编译报错）。
  效果：我们废弃了所有架构文档PDF，只保留/docs/architecture-rules.md，里面只有3句话：“1) 所有API调用走requestClient；2) 所有状态变更走store.dispatch；3) 所有UI组件用<script setup>语法”。其余细节，都在代码和CI里。

误区三：“AI能替代架构师做决策”
现象：团队采购AI编程工具后，要求架构师“让AI设计新系统的架构”，结果AI输出一份包含Serverless、WebAssembly、GraphQL的炫酷方案，但团队连TypeScript都没用熟。
后果：方案无法落地，团队信心受挫，认为“AI不靠谱”。
纠正方案：明确AI的“能力坐标系”，只让它做坐标系内工作。

• X轴（技术成熟度）：AI只能处理团队已掌握的技术栈（如已用Vue3，则AI可辅助Vue3组件开发；未用过Qwik，AI不得推荐Qwik方案）；
• Y轴（问题确定性）：AI只解决有明确输入输出的问题（如“优化这个函数性能”），不解决模糊问题（如“如何提升用户体验”）；
• Z轴（风险承受力）：AI生成的代码，必须通过团队定义的“安全阈值”（如单元测试覆盖率≥80%，ESLint零错误，Bundle体积增幅≤5KB）。
  实操案例：我们设定AI的“能力坐标”为：X=Vue3/Vite/Pinia，Y=代码优化/缺陷检测/文档生成，Z=所有AI输出必须通过CI三道关卡。超出坐标的请求，AI回复：“此任务超出我的能力范围，请联系架构师”。

误区四：“架构演进等于技术升级”
现象：团队每年强制升级一次技术栈（如“今年必须用React18”“明年必须上RSC”），不管业务是否需要，也不评估迁移成本。
后果：开发者疲于应付升级，核心业务功能迭代停滞，技术债越积越多。
纠正方案：建立“技术债仪表盘”，用数据驱动演进决策。

• 每周自动采集：1）构建耗时（分钟）；2）CI失败率（%）；3）平均PR合并时间（小时）；4）线上前端错误率（/1000 PV）；5）开发者满意度调研（NPS）。
• 当任一指标连续3周恶化超阈值（如构建耗时>10分钟），触发“技术债根因分析”，只有确认是技术栈陈旧导致，才启动升级。
  效果：我们曾因CI失败率飙升，深入分析发现是Webpack5的cache配置不当，而非Webpack版本问题，修复配置后失败率回归正常，避免了一次不必要的升级。

提示：所有纠正方案，都遵循“最小干预原则”——用最少的改动，解决最痛的问题。架构优化不是追求完美，而是让团队今天比昨天少踩一个坑。

4.2 架构问题排查黄金流程

当线上出现“页面白屏”“状态丢失”“性能骤降”等典型架构级问题时，靠直觉排查效率极低。我们沉淀出一套标准化的“五步排查法”，每步都有具体命令和判断依据。

第一步：锁定问题域（Isolate the Domain）
目标：快速区分是前端问题、后端问题、还是环境问题。

• 执行：打开浏览器DevTools → Network标签 → 刷新页面 → 观察：
  • 若所有API请求（XHR/Fetch