硬编码问题分析报告

问题概述

经过全面检查，发现项目中存在多处硬编码问题，主要集中在比赛阶段名称的处理上。这些硬编码会导致系统在用户自定义阶段名称时出现功能异常。

发现的硬编码问题

1. 后端服务层硬编码（严重）

文件： backend/src/main/java/com/rongyichuang/player/service/PlayerApplicationService.java
位置： 第35行
问题代码：
java // 默认只显示海选阶段的数据，过滤掉复赛等后续阶段 whereClause.append("(stage.name NOT LIKE '%复赛%' AND stage.name NOT LIKE '%决赛%')");

问题分析：
- 硬编码了"复赛"和"决赛"字符串
- 如果用户自定义阶段名称（如"第二轮"、"半决赛"等），过滤逻辑将失效
- 这是最严重的硬编码问题，直接影响业务逻辑

2. 前端界面硬编码（中等）

文件： web/src/views/ActivityForm.vue
位置： 第668行
问题代码：
javascript const stageNames = ['', '海选', '复赛', '半决赛', '决赛', '总决赛']

问题分析：
- 硬编码了默认阶段名称数组
- 限制了用户的自定义能力
- 不够灵活，无法适应不同类型的比赛

3. 前端比赛晋级页面硬编码（中等）

文件： web/src/views/competition-promotion/index.vue
位置： 第300行、第310行、第430行
问题代码：
javascript stageName: '初赛', stageName: '决赛', currentStageName: '初赛'

问题分析：
- 模拟数据中硬编码了阶段名称
- 可能影响测试和开发环境的数据一致性

4. 数据库测试数据硬编码（轻微）

文件： db.sql
位置： 第39-45行
问题代码：
sql INSERT INTO `t_activity` (..., `name`, ...) VALUES (..., '海选', ...); INSERT INTO `t_activity` (..., `name`, ...) VALUES (..., '复赛', ...);

问题分析：
- 初始化数据中硬编码了阶段名称
- 虽然是测试数据，但可能误导开发者认为这是标准命名

根本原因分析

1. 缺乏阶段类型设计

• 数据库表 t_activity 中只有 sort_order 字段表示阶段顺序
• 缺少 stage_type 或 stage_level 字段来标识阶段类型
• 业务逻辑依赖阶段名称而非阶段类型

2. 过滤逻辑设计不当

• 使用字符串匹配而非结构化字段进行过滤
• 没有考虑用户自定义阶段名称的场景

修改建议

方案一：添加阶段类型字段（推荐）

1. 数据库结构修改
   sql ALTER TABLE t_activity ADD COLUMN stage_type INT DEFAULT 1 COMMENT '阶段类型：1=初选阶段，2=中级阶段，3=高级阶段';

2. 后端服务修改
   java // 替换硬编码的字符串匹配 // 原代码：whereClause.append("(stage.name NOT LIKE '%复赛%' AND stage.name NOT LIKE '%决赛%')"); // 新代码： whereClause.append("stage.stage_type = 1"); // 只显示初选阶段

3. 前端界面修改

• 在活动创建表单中添加阶段类型选择
• 移除硬编码的阶段名称数组
• 允许用户自定义阶段名称

方案二：基于排序顺序过滤（备选）

1. 后端服务修改
   java // 基于sort_order过滤，只显示第一阶段 whereClause.append("stage.sort_order = 1");

2. 优点： 无需修改数据库结构

3. 缺点： 灵活性较差，无法支持复杂的阶段分类

方案三：配置化阶段管理（最佳）

1. 创建阶段类型配置表
   sql CREATE TABLE t_stage_type ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL COMMENT '阶段类型名称', code VARCHAR(20) NOT NULL COMMENT '阶段类型代码', level INT NOT NULL COMMENT '阶段级别', is_initial BOOLEAN DEFAULT FALSE COMMENT '是否为初选阶段', description VARCHAR(255) COMMENT '描述' );

2. 修改活动表
   sql ALTER TABLE t_activity ADD COLUMN stage_type_id BIGINT COMMENT '阶段类型ID';

3. 业务逻辑修改
   java // 基于阶段类型配置进行过滤 whereClause.append("EXISTS (SELECT 1 FROM t_stage_type st WHERE st.id = stage.stage_type_id AND st.is_initial = true)");

实施优先级

1. 高优先级： 修复 PlayerApplicationService.java 中的硬编码过滤逻辑
2. 中优先级： 修改前端阶段名称硬编码
3. 低优先级： 清理测试数据中的硬编码

风险评估

• 高风险： 后端过滤逻辑修改可能影响现有数据查询
• 中风险： 数据库结构修改需要数据迁移
• 低风险： 前端界面修改相对安全

建议实施步骤

1. 首先实施方案二（基于排序顺序），快速解决当前问题
2. 然后逐步实施方案三（配置化管理），提供长期解决方案
3. 最后清理所有相关的硬编码问题

总结

项目中的硬编码问题主要源于缺乏合理的阶段类型设计。建议采用配置化的方式管理阶段类型，既能解决当前的硬编码问题，又能为未来的功能扩展提供良好的基础。