# 组件复用性分析与优化计划

## 项目概述
对药品查询微信小程序进行全面的组件复用性分析与优化，建立标准化的组件体系，提升代码质量和开发效率。

## 执行步骤

### 第一阶段：组件梳理与评估（预计2-3小时）

#### 1.1 组件盘点
- [ ] 扫描项目所有页面和组件目录
- [ ] 识别所有自定义组件（components目录）
- [ ] 识别页面内重复使用的UI片段
- [ ] 识别可复用的业务逻辑模块

#### 1.2 复用价值评估
建立评估矩阵，从以下维度评估：
- 使用频率（≥3次为高频）
- 功能独立性（是否耦合业务逻辑）
- 通用性（跨页面/跨业务可用性）
- 复杂度（提取难度）

### 第二阶段：公共控件提取（预计4-6小时）

#### 2.1 基础组件提取
- [ ] **导航栏组件（navbar）** - 已存在，评估优化空间
- [ ] **分页组件（pagination）** - 已存在，评估使用一致性
- [ ] **弹窗组件（popup）** - 已存在，评估功能扩展
- [ ] **标签栏组件（doctor-tab-bar/ground-tab-bar）** - 评估合并可能性

#### 2.2 业务组件提取
- [ ] **项目选择器** - 地推端/药店端/患者端均有项目切换功能
- [ ] **日期选择器** - 多处使用日期范围选择
- [ ] **状态标签** - 审核状态、跳转状态等标签展示
- [ ] **患者卡片** - 患者列表卡片展示
- [ ] **统计卡片** - 首页统计数据展示卡片

#### 2.3 复合组件提取
- [ ] **上传材料弹窗** - popup + 上传功能的复合组件
- [ ] **筛选栏组件** - 搜索+筛选条件的组合

### 第三阶段：组件体系构建（预计2-3小时）

#### 3.1 目录结构规划
```
src/
├── components/
│   ├── base/           # 基础组件
│   │   ├── navbar/
│   │   ├── pagination/
│   │   └── popup/
│   ├── business/       # 业务组件
│   │   ├── project-picker/
│   │   ├── date-picker/
│   │   ├── status-tag/
│   │   └── patient-card/
│   └── composite/      # 复合组件
│       ├── upload-material/
│       └── filter-bar/
```

#### 3.2 命名规范制定
- 基础组件：小写短横线命名
- 业务组件：业务前缀+功能命名
- 复合组件：功能组合命名

### 第四阶段：组件文档编写（预计3-4小时）

为每个提取的组件编写：
- 功能描述
- 使用场景
- 参数列表（类型、默认值、必填、说明）
- 使用示例
- 事件回调说明
- 注意事项

### 第五阶段：代码替换实施（预计6-8小时）

#### 5.1 组件替换
- [ ] 替换地推端首页项目选择器
- [ ] 替换药店端首页项目选择器
- [ ] 替换患者端首页项目选择器
- [ ] 替换患者列表日期筛选
- [ ] 替换统计页面日期筛选
- [ ] 替换审核状态标签
- [ ] 替换患者卡片

#### 5.2 验证测试
- [ ] 功能完整性测试
- [ ] 样式一致性测试
- [ ] 交互逻辑测试

### 第六阶段：成果交付（预计2小时）

#### 6.1 文档输出
- [ ] 组件复用性分析报告
- [ ] 组件库目录结构说明
- [ ] 组件使用文档
- [ ] 代码替换实施指南

#### 6.2 代码审查
- [ ] 组件代码质量检查
- [ ] 引用替换完整性检查

## 预期成果

1. **组件库目录**：标准化的组件分类体系
2. **公共组件**：提取5-8个高频复用组件
3. **技术文档**：完整的组件使用文档
4. **代码优化**：减少重复代码30%以上

## 时间预估
总计：约19-26小时

## 风险评估

| 风险点 | 影响 | 应对措施 |
|--------|------|----------|
| 组件耦合度高 | 提取困难 | 先解耦再提取 |
| 样式差异大 | 统一困难 | 制定样式规范 |
| 替换影响功能 | 回归测试 | 分阶段替换验证 |

## 下一步行动

等待用户确认计划后，开始第一阶段：组件梳理与评估。