Mahiro-Blog 二开实战（一）：组件重构与可维护目录拆分

当你从“改皮肤”进入“改功能”阶段，第一件事通常不是写新代码，而是重构目录和组件边界。

这篇文章专注一个目标：让你的二开版本三个月后还看得懂、改得动。

1. 为什么二开先做组件重构

常见现状：

• 页面能跑，但组件职责混乱
• 一改样式就影响别处
• 同一逻辑散落在多个文件

重构不是为了“好看”，是为了减少未来每次改动的风险半径。

2. 一个实用的拆分原则

建议按三层拆：

1. 页面层（src/pages）：负责路由与组装
2. 业务组件层（src/components）：负责交互和展示
3. 工具层（src/lib / src/utils）：负责纯逻辑

页面层尽量“薄”，避免把业务逻辑写死在页面里。

3. 二开时最值得先抽离的模块

优先抽离这些“高复用且高变动”的块：

• 导航栏状态逻辑
• 卡片列表渲染逻辑
• 筛选/搜索逻辑
• 配置读取逻辑

这样你后面做新页面时，几乎可以直接复用。

4. 重构中的防回归策略

每次重构建议只做一个动作：

• 先“搬运不改逻辑”
• 再“微改结构”
• 最后“清理冗余”

每一步都跑：

pnpm check
pnpm build

避免一次大改导致定位困难。

5. 常见反模式（尽量避开）

5.1 巨型组件

一个组件超过 300 行且混合了状态、请求、渲染，后续会非常难维护。

5.2 页面里直接写业务逻辑

页面应主要负责拼装。逻辑放页面会导致复用困难。

5.3 工具函数依赖 UI 状态

工具层要尽量纯函数化，否则测试和迁移成本高。

6. 适合 Mahiro-Blog 的重构节奏

• 周期一：先拆导航/卡片/列表
• 周期二：抽离配置消费与数据映射
• 周期三：整理动画与交互层

先稳结构，再追求炫技。

系列导航（二开实战）

二开总览入口