框架选型与迁移决策

• 评估维度的选取（团队、生态、性能、类型、SSR）
• 权重设定与评分方法
• 决策输出的落地（文档、风险、复核机制）

决策矩阵的构建分三步：定义维度、设定权重、逐项评分。维度通常包括：团队技能与招聘（熟悉度、学习成本、人才池）、生态与组件库（覆盖度、第三方库、工具链）、性能与体积（首屏 JS、更新模型、基准数据）、TypeScript 与类型安全、SSR/全栈能力、长期维护（治理、发布节奏）、社区活跃度。示例画像：React/Vue 生态与招聘得分高、性能中等；Svelte/Solid 性能与体积领先、生态较薄；Angular 企业级规范与全栈能力强、学习曲线陡。

权重由项目约束决定：交付周期紧、团队固定抬升"团队技能"；性能敏感（大列表、低端设备）抬升"性能"；长期产品抬升"维护与招聘"。评分以可核验事实为准（官方文档、js-framework-benchmark、npm 趋势、岗位数量），加权汇总后做敏感性分析（权重变化是否改变结论），最后输出选型文档：推荐结论、对比表、风险清单与"再评估触发条件"（如业务形态变化、性能不达标）。矩阵的价值在于把偏好争论转化为可审计的量化比较。

本题考察选型方法论。回答要点是"维度—权重—评分—敏感性—文档"的完整闭环，强调权重由项目约束决定、评分基于事实数据，避免拍脑袋选型。

• 各维度的量化评分标准
• 权重与项目形态的匹配
• 敏感性分析与结论稳定性

每个维度先定义可操作的评分标准：团队熟悉度按"熟练成员占比、过往项目数、预估上手周期"评分；生态成熟度按"核心库覆盖度、组件库质量、文档完整度、CVE 响应速度"评分；性能需求按"体积预算达成度、基准测试数据、目标设备基线"评分；长期维护性按"发布纪律（semver/LTS）、治理结构（基金会/公司投入）、升级工具成熟度"评分；招聘市场按"岗位数量、社区规模、培训资源"评分。

加权逻辑与项目形态绑定：企业级后台/交付型项目（周期紧、团队固定）抬升团队熟悉度与生态权重；性能敏感产品（列表密集型、弱网设备）抬升性能权重；平台型长期项目抬升维护性与招聘权重。权重归一化后计算加权总分，并对关键假设（如性能预算是否达标、团队能否快速补足技能）做敏感性分析，验证结论对权重波动的稳定性；最终形成"主推方案 + 备选方案 + 关键风险"的评估结论。量化模型的真正价值是权重透明、可争论、可复盘，而非给出唯一正确答案。

本题考察量化模型的构建细节。回答要点：维度评分标准定义、权重与项目形态绑定、敏感性分析保证结论稳健，强调过程透明比数字精确更重要。

• 破坏性变更评估与官方迁移工具
• 渐进迁移（逐模块/双轨运行）的路径
• 风险控制：测试、灰度、回滚

迁移路径分四步：评估（梳理破坏性变更——Vue 2→3 的 Composition API/v-model/filters/全局 API 变化，React 16→18 的 createRoot、并发渲染、StrictMode 行为差异，逐个盘点影响面）；自动化转换（vue-codemod、react-codemod 等官方工具批量改写 API 调用，剩余手工处理）；渐进替换（新功能用新版本编写，存量按模块/页面分批迁移，必要时用微前端或独立入口并行运行新旧两套，通过共享网关与样式隔离衔接）；收尾（移除兼容层与旧版本代码）。并行运行期间新旧应用的会话、路由与状态需统一设计（统一域名与导航、共享登录态）。

风险控制闭环：行为对比测试（新旧版本对同一交互的输出对比）与快照测试、组件级兼容层（适配器包装旧 API）、分阶段灰度（按路由/按流量比例放量）、全链路观测（错误率、性能指标）与一键回滚机制；每个迁移批次独立提交与发布，问题可定位到批次。原则是"分批替换、双轨可退、可观测可回滚"，避免大爆炸式迁移。

本题考察迁移工程的方法论。回答要点：评估—codemod—渐进迁移—收尾的路径，以及"测试对比 + 灰度 + 回滚"的风险控制闭环。

• 技能分布与上手/维护成本的量化
• 生态活力指标（贡献者、发布、依赖健康）
• 治理结构与公司背书的辨析

团队技能分布决定"上手成本与维护风险"：已有熟练成员的框架降低培训成本与排错风险，可量化评估（熟练人数占比、团队历史代码占比、招聘池供给）；技能缺口大意味着学习曲线、代码质量风险与关键人物依赖（单点维护）。选型时把"团队能否在合理周期内达到合格水平"作为硬约束，而非只比框架本身优劣；同时评估长期的学习成本（新 API 持续涌现带来的知识折旧）。

长期活力评估：量化指标看 npm 下载趋势（是增长还是萎缩）、GitHub 活跃（提交频率、贡献者多样性、PR/issue 处理速度）、发布节奏与版本纪律（semver、LTS 承诺）、依赖健康（陈旧依赖、供应链风险、CVE 响应）；质性指标看治理结构（公司背书 vs 基金会托管 vs 个人项目）、RFC 与决策流程透明、文档与迁移指南质量。警惕"star 高但维护停滞"与"单点维护者"的风险信号；公司背书要区分"使用背书"与"实质投入（全职团队）"。

本题考察技能存量与生态活力的评估方法。回答要点：技能分布量化影响选型约束、活力指标分"活跃度/纪律/治理"三层，识别虚假热度与单点风险。

• 迁移成本的构成（人力、机会成本、回归风险）
• 渐进迁移的隔离与分步验证
• 整体重写的"第二系统"风险

成本模型 = 迁移人力（改造工时 + 双轨维护）× 周期 + 业务迭代停滞的机会成本 + 回归风险折算（故障概率 × 影响） + 技术债清偿后的长期收益（性能、维护效率、招聘）。渐进迁移把大爆炸风险拆解为可验证的小步：通过微前端容器或路由级隔离，新框架区域与旧框架区域并存，每步独立发布、独立回滚，风险线性可控、可随时暂停；代价是长期双轨成本（两套工具链、双份维护）与集成复杂性。整体重写：短期成本集中、风险高——功能隐性需求丢失、回归面巨大，且"第二系统效应"（重写时过度设计）常导致周期与成本失控。

决策原则：旧系统可演进（架构未僵化、可增量改造）则渐进迁移；仅在架构僵化、性能瓶颈不可修、技术债拖垮迭代时考虑重写，且重写必须有明确范围契约（功能清单冻结）、充分的自动化测试基线、流量对比（新旧并行灰度）与止损机制。收益兑现依赖迁移后持续投入，而非"重写即成功"。

本题考察迁移的成本与风险建模。回答要点：成本构成拆解、渐进迁移"以时间换风险"与重写"以风险换时间"的对比、重写的前置条件与止损设计。

• 多框架的运行时重复与体积预算
• 子应用边界与通信契约的治理
• 沙箱与依赖共享的取舍

多框架共存的价值是技术异构的渐进迁移与独立交付，但成本显著：每引入一套框架就多一份运行时与工具链，同页混用时包体与内存翻倍，沙箱（JS 隔离、样式隔离）与动态加载也有开销。性能治理：设定框架预算（单页框架数量上限、子应用体积阈值）、公共依赖 external 化共享（module federation 的 shared、import-map 单一化）、按路由懒加载子应用、监控首屏体积与 TTI 指标防回归。

工程治理：统一路由基座与子应用生命周期契约（挂载/卸载/通信规范）、明确通信协议（自定义事件、全局 store 或 URL 状态，禁止跨子应用直接引用组件）、共享设计系统与基础库（设计 token 与公共组件抽为独立包）、构建产物规范（独立 chunk、稳定入口、版本化）、样式隔离约定与契约测试。权衡原则：混用是过渡手段而非目标，能单框架就不混用，混用必须限数量、定边界、有预算。

本题考察多框架微前端的治理体系。回答要点：性能上的运行时重复与预算控制、治理上的契约化边界与共享资产、以及"混用是过渡手段"的原则判断。

• 四个维度的具体评估要点
• 维度权重与项目约束的映射
• 评估数据的可核验性与落地

团队维度：技能存量（熟练人数、历史代码）、学习曲线（官方文档质量、上手周期）、维护可替代性（人员流动时谁能接手）；性能维度：首屏 JS 体积（gzip/brotli）、更新模型（虚拟 DOM vs 细粒度）、可复现基准（js-framework-benchmark）、体积预算达成度；生态维度：组件库覆盖（UI、表单、图表、状态、SSR）、第三方库活跃度、文档与工具链、CVE 响应与安全；长期维护维度：版本节奏与 semver/LTS 纪律、治理结构（基金会/公司投入）、升级工具（codemod、迁移指南）、社区健康度（贡献者多样性、问题处理速度）。

评估时把项目约束（性能预算、上线时间、团队规模、行业合规）映射为维度权重，用可核验数据打分（构建产物实测、基准复测、GitHub/npm 数据），输出选型报告（结论、对比、风险、备选），并设定再评估触发条件（业务形态变化、关键指标不达标）。维度决定"比什么"，权重决定"多重要"，数据决定"怎么判"，三者缺一不可。

本题考察评估维度的系统化拆解。回答要点：四个维度的可操作评估要点、约束到权重的映射、可核验数据与再评估机制。

• 三者的渲染模式与框架定位
• 全栈应用 vs 内容站的边界判断
• 岛屿架构与多框架的适用场景

Next.js（React）是全栈应用框架：SSR/SSG/ISR、流式渲染、App Router 服务端组件、中间件，适合复杂交互应用与深度 SEO 需求；Nuxt（Vue）是 Vue 生态的全栈框架：SSR/SSG/混合渲染、模块体系（Nuxt Content、Auth、i18n）、自动导入，适合 Vue 团队的应用与内容混合站点；Astro 是内容优先框架：默认零 JS 静态输出、岛屿部分水合、多框架集成（React/Vue/Svelte 岛屿），适合文档、博客、营销页与"少量交互"的站点。

边界判断：交互复杂度高、需要服务端状态与实时数据、应用型产品 → Next/Nuxt（按团队技术栈选）；内容驱动、SEO 优先、交互点缀 → Astro；混合诉求可组合（Astro 嵌框架岛屿，或用 Nuxt/Next 的 SSG 模式做内容页）。次要因素：团队语言栈（React 生态→Next，Vue 生态→Nuxt）、部署形态（静态平台 vs Node/serverless）、岛屿式多框架需求（Astro 独特优势）。本质是"应用框架 vs 内容框架"的定位差异。

本题考察三大框架的边界划分。回答要点：各自的渲染能力与定位、按"交互复杂度 × 内容属性 × 团队栈"判断边界、组合使用的可能性。

• 基准方法论：统一场景与固定环境
• 指标解读：创建/更新/内存/体积
• 基准之外的真实页面验证

可复现基准的方法论：js-framework-benchmark 提供统一场景（创建/替换/更新/清除千行表格、选择行、部分更新等）与固定运行环境（同硬件、同浏览器、同测量协议），各框架以同等优化水平参赛，输出操作耗时、内存峰值、脚本执行时间、首屏体积等指标；对比时注意版本一致、同等级优化（compiled vs hand-optimized）、多次运行取统计量（避免偶然性）。首屏体积对比应基于实际构建产物（gzip/brotli 压缩后），并对照项目的体积预算；交互性能关注更新延迟与长任务阻塞；内存关注峰值占用与稳定性（GC 行为）。

横向对比的局限：基准场景（大列表增删改）未必代表业务形态，应选取与业务相近的基准结果；基准回答"相对差距"，真实页面（LCP/INP/TBT 实测）回答"是否达标"。实践：先跑基准缩小候选，再用原型页面在目标设备上验证，把体积预算与性能预算写入 CI 防止回归。

本题考察基准对比的方法论。回答要点：统一场景与固定环境的可复现性、三类指标的解读、基准与真实页面验证的互补关系。

• 独立部署与依赖共享的平衡
• 沙箱、运行时与依赖重复的成本
• 治理规范与体积预算机制

微前端 + 多框架的核心矛盾是"组织自治"与"运行时成本"：子应用独立开发部署带来效率，但每套框架的运行时、重复的 UI 库版本、沙箱隔离（JS 隔离、样式隔离、全局变量隔离）都会增加体积与性能开销。性能权衡手段：公共依赖 external 化共享（module federation 的 shared、single-spa 的 import-map），让 React/Vue 等基础运行时与常用库全局单例；按路由/按需加载子应用（不加载非当前子应用的代码）；设置框架与体积预算（同页框架数 ≤ 2、子应用首屏体积阈值）并在 CI 卡点。

工程治理：统一基座与生命周期契约（mount/unmount、路由接入、样式约定）、通信契约（事件/URL/全局 store，禁止直接依赖内部实现）、构建产物规范（独立 chunk、稳定入口、版本化、公共依赖标记）、版本管理策略（共享库版本兼容、升级同步窗口）。原则：为真实的团队边界引入微前端，避免"为技术而技术"；混用数量受限、边界契约化、成本有预算、收益可度量。

本题考察微前端多框架的权衡框架。回答要点：运行时重复与沙箱成本、依赖共享与按需加载的性能手段、契约化治理与预算机制，强调组织需求驱动技术形态。

• 活性指标：贡献者、发布、问题处理
• 治理结构与投入实质
• 风险信号与验证方法

长期活力的验证要区分"热度"与"活性"：热度（star、媒体报道）是滞后指标，活性看持续投入。量化指标：GitHub 提交频率与贡献者多样性（是否多个组织/个人长期投入）、PR 与 issue 的平均处理时长、发布节奏与版本纪律（semver 执行、LTS 承诺、破坏性变更是否只在 major）、CVE 响应速度、文档与示例的更新频率；生态侧看第三方库适配、课程与招聘趋势。治理结构：公司背书要辨别"使用背书"与"实质投入"（全职维护团队、资金与基础设施支持）；基金会托管通常意味着更稳定的治理与决策流程；RFC/决策流程透明说明演进可预期。

风险信号：单点维护者（核心作者停止维护即项目停滞）、star 与 commit 严重背离、频繁破坏性变更且迁移工具缺失、issue 长期无人处理、缺少清晰的版本承诺。验证方法：看发布历史的时间序列（而非最新状态）、读迁移文档与 changelog 质量、查贡献者画像、与维护者/社区互动反馈时效。结论：活性看"可持续投入与治理"，而非一时热度。

本题考察生态活力的辨别方法。回答要点：热度与活性的区分、活性指标的时间序列观察、治理投入实质的辨别与风险信号清单。

• 逐组件/逐页面的替换顺序
• 双框架共存的隔离边界
• 状态与路由的统一设计

渐进迁移的核心是"稳定边界 + 分批替换"：先从低耦合的叶子组件或独立页面开始，新组件用目标框架编写、旧组件保留，形成新旧混用期；双框架共存通过隔离机制实现——微前端容器（按路由/区域划分应用边界）、自定义元素包装（Web Component 封装目标框架组件供另一框架调用）、或 iframe 级隔离（极端场景）。替换顺序遵循"依赖关系自底向上"：先替换无依赖的展示组件，再替换容器与页面，避免中间态出现双向依赖。

统一设计先行：状态层抽成框架无关的共享层（跨框架 store，如 zustand/pinia 的统一抽象或事件协议），路由由外层基座统一控制，样式与设计系统先统一（token 与规范先行）避免视觉分裂；数据契约（API、类型）文档化，保证新旧组件协同不回归。每个替换周期做行为对比测试与灰度，逐步收缩旧框架面积直到完全移除；风险控制与 Vue 2→3、React 16→18 迁移一致（测试基线、灰度、回滚）。

本题考察跨框架迁移的渐进策略。回答要点：自底向上的替换顺序、双框架共存的隔离手段（微前端/自定义元素）、状态与路由的统一设计先行。

• 升级成本的构成（人力、依赖链、回归）
• 破坏性变更的影响面评估
• lockfile 锁定与升级节奏策略

升级成本 = 迁移人力（codemod 自动转换 + 手工修复）× 周期 + 依赖链升级（周边库适配新版本、peer 依赖冲突解决）+ 回归测试（功能、性能、构建产物对比）+ 文档与团队培训。破坏性变更管理：逐条核对官方 changelog 与迁移指南，评估影响面（API 移除、默认行为变化、构建产物变化、类型变化），建立变更清单并分配负责人与验证用例；优先处理影响面大、难以自动检测的变更。

依赖锁定：lockfile 锁定精确版本保证构建可复现、避免无声升级；但长期不升级会累积技术债与 CVE 风险。策略：小步高频升级（跟随 minor/patch，避免跨多个 major 跳升）、升级窗口化（按季度集中处理）、自动化依赖更新（renovate/dependabot）配合 CI 回归、重大版本升级前做兼容预演（peer 依赖检查、在分支上验证构建与测试）、保留可回滚的发布机制。锁定防漂移，节奏防积债，两者平衡是依赖管理的核心。

本题考察框架升级的成本管理。回答要点：成本四要素拆解、破坏性变更的影响面评估流程、锁定与升级节奏的平衡策略。

• 分层规范：工程、框架使用、协作
• 共享库的框架无关设计
• 框架边界与共享资产的分层

多框架治理分三层：工程规范（lint/format/commit/CI/构建约定统一，团队共享的基础设施）、框架使用规范（每个框架的目录结构、状态管理约定、性能红线、错误处理与可观测性接入文档）、协作规范（代码评审清单、变更记录、契约测试要求）。目标是把框架差异"局部化"，让跨框架协作成本可控。

共享库设计遵循"框架无关资产下沉、框架专属资产隔离"：设计 token（颜色/间距/字体）、工具函数、类型定义、API 客户端、数据层可以抽为框架无关的公共包；UI 设计系统按框架分别实现，但共享 token 与交互规范（或用 Web Component 统一承载）；跨框架状态通过统一协议（事件/存储）而非互相引用。边界原则：公共逻辑下沉共享库、框架实例不互渗（不互相 import 组件）、依赖方向单向（应用 → 共享库）。共享库用版本化发布（独立 changelog 与升级窗口），避免"公共代码失控"。

本题考察多框架团队的治理体系。回答要点：三层规范结构、共享库的框架无关设计（token/工具/协议下沉）、依赖方向与版本化发布原则。

• 版本节奏与升级成本的关系
• 学习成本与知识折旧的长期评估
• 维护预算的测算方法

版本节奏决定长期维护成本：迭代快的框架带来新能力与性能改进，但频繁升级消耗维护预算；评估要点是版本纪律（semver 是否严格执行、破坏性变更是否只在 major）、LTS 承诺（安全与修复支持时长）、升级工具自动化程度（codemod 覆盖率）、发布频率与升级窗口的匹配。节奏慢的框架稳定但可能错过性能/安全改进；节奏快但升级顺畅（工具+文档）优于节奏慢但升级痛苦。

学习成本是隐性长期成本：新 API 持续引入带来知识折旧（团队需持续跟进文档与培训）、招聘与交接成本、以及"旧知识失效"的迁移负担；评估时应测算 3-5 年周期内的总维护成本 = 升级频率 × 单次升级难度 + 持续学习投入，而非只比较初始上手难度。决策启示：长期项目优先选择"发布纪律好 + 升级工具成熟 + 知识折旧可控"的框架，为维护预算留出明确额度。

本题考察长期维护成本的量化思维。回答要点：版本纪律与 LTS 决定升级可预期性、知识折旧是隐性成本、用"周期总成本"而非初始难度决策。

• 需要的信号：组织规模、独立交付、渐进迁移
• 过度的信号：小团队、同质业务、无独立发布需求
• 替代方案与判断标准

需要微前端/多框架共存的信号：大型组织的多个团队独立交付（各自发布节奏与发布权）、技术异构（并购整合、历史包袱）、渐进迁移期的双轨运行、需要独立扩展与故障隔离（子应用崩溃不拖垮整站）。此时微前端提供的"组织自治 + 技术隔离"是真实收益。过度设计的信号：团队小（一两个小组）、业务同质（单一领域）、无独立发布需求、沟通成本低——此时微前端带来的沙箱开销、依赖重复、调试复杂度和性能损耗远超收益，属于为技术而技术。

替代方案：monorepo 统一仓库（共享代码与依赖、统一 CI）+ 组件库 + 模块化设计，或直接统一框架；需要团队边界时先用"模块边界 + 代码规范"模拟，而不是直接上微前端。判断标准：先回答"组织是否需要独立部署与团队自治"，再回答"技术方案是否匹配"，微前端是组织架构的镜像——没有组织需求就没有技术需求；已上微前端的团队也应在业务收敛时评估"反治理"（合并子应用）的时机。

本题考察微前端的适用性判断。回答要点：真实需求信号（组织自治、独立交付、渐进迁移）、过度信号（小团队同质业务）、替代方案与"组织驱动技术"的判断标准。

• codemod 的 AST 批量重构与回归保障
• 官方升级指南与迁移清单的执行顺序
• 兼容层的过渡期设计与逐步移除

codemod（基于 jscodeshift 等 AST 工具）对源码做结构化的批量改写：按官方规则把旧 API 调用转换为新写法，覆盖大量机械性变更（重命名、参数迁移、选项改写），显著降低手工工作量；配合类型检查、单测/快照测试与构建验证做回归把关，codemod 后残留的手工清单由迁移指南补全。官方升级指南（migration guide + 官方 codemod 包）提供经过验证的迁移路径与顺序（如"先升级依赖再改代码、先数据层后视图层"），按序执行减少遗漏；同时可对比升级前后行为（输出快照、性能基线）。

兼容层设计：在过渡期用适配器/双 API 共存（deprecated 保留 + 新 API 并行）、polyfill 补行为差异，让新旧代码并存、逐步切换，每批组件迁移后移除对应兼容代码；配合灰度（按流量/路由放量）与观测（错误率、性能指标）验证兼容层覆盖是否正确，最终在全部迁移完成后清理兼容层，避免长期维护两套 API。风险控制闭环：变更清单 → codemod + 手工 → 测试/类型/行为对比 → 灰度 → 观测回滚，每个批次独立提交便于二分定位问题。

本题考察自动化工具链在迁移中的应用。回答要点：codemod 的 AST 批量重构与回归保障、升级指南的执行顺序、兼容层的过渡与移除节奏，以及灰度观测闭环。