# mynetspeeder 项目问题清单

> 说明：本文只做项目体检，不修改代码。按“高风险 / 中风险 / 低风险”排序，优先列出最可能影响稳定性、排障和后续维护的问题。

## 高风险

1. **配置缺少严格校验**
   - 位置：`config.py:54-89`
   - 问题：`Config.load()` 直接读取 JSON 并套默认值，缺少字段类型、取值范围、必填项的统一校验。
   - 影响：配置写错后往往不是启动时立即失败，而是运行一段时间后才在网络路径、重连或统计逻辑里暴露，排查成本高。

2. **并发状态机复杂，容易出现隐性竞态**
   - 位置：`relay_client.py:49-235`、`transparent_edge.py:197-847`、`socks_edge.py:241-680`
   - 问题：连接、会话、winner 选择、重连、关闭清理都依赖大量异步任务和共享状态。
   - 影响：在高并发、短连接、抖动网络、对端异常关闭时，可能出现“会话已关但任务还在跑”“winner 已切换但旧路径未及时收敛”等边界行为。

3. **异常处理偏宽，真实错误容易被吞掉**
   - 位置：`relay_client.py`、`relay_server.py`、`transparent_edge.py`、`socks_edge.py`
   - 问题：项目里大量使用 `except Exception`，部分分支只做 `pass` 或简单打印。
   - 影响：服务能尽量不中断，但很多根因不会被结构化记录，后续定位问题主要依赖人工翻日志。

4. **日志格式强依赖，汇总结果脆弱**
   - 位置：`cli.py:18-295`
   - 问题：`summary` 通过正则解析运行日志，完全依赖日志文本格式稳定。
   - 影响：只要日志文案略有调整，统计结果就可能漏算或错算，适合临时分析，不适合作为长期可靠报表源。

## 中风险

1. **缺少自动化测试覆盖**
   - 位置：仓库当前未见测试文件
   - 问题：网络代理、中继、UDP 竞速、透明接管这类逻辑对回归特别敏感，但目前没有明显的单测或集成测试保护。
   - 影响：改动一处逻辑，可能在另一路径上引入回归，尤其是重连、关闭、UDP 分包和 winner 收敛场景。

2. **日志输出偏“人读友好”，不够机器化**
   - 位置：`relay_client.py`、`relay_server.py`、`transparent_edge.py`、`socks_edge.py`
   - 问题：当前更多是 `print(...)` 风格输出，缺少统一级别、字段、结构化上下文。
   - 影响：排障时可以看，但想做持续监控、指标采集、告警联动会比较费劲。

3. **UDP 路径语义较复杂，文档和实现容易产生认知偏差**
   - 位置：`README.md`、`scripts/start-transparent.sh`、`socks_edge.py`、`transparent_edge.py`
   - 问题：当前有“UDP 透明接管”和“显式 SOCKS5 UDP ASSOCIATE”两套入口，且 `socks_port > 0` 时会优先走 SOCKS 入口。
   - 影响：如果用户只看配置字面意思，容易误以为 UDP 透明和 SOCKS UDP 会同时生效，实际行为需要结合启动脚本理解。

4. **重连与健康检查阈值偏经验化**
   - 位置：`config.py:31-38`、`relay_client.py:60-75`、`scheduler.py:24-58`
   - 问题：重连间隔、ping 超时、open timeout、probe timeout 都是经验值。
   - 影响：在不同网络质量下，过于激进会误判，过于保守会拖慢故障恢复。

5. **统计与调度逻辑耦合在一起，后续可维护性一般**
   - 位置：`scheduler.py`、`cli.py`
   - 问题：调度器和状态统计、探测输出、汇总逻辑之间复用不多，更多是“当前能用”。
   - 影响：未来如果要增加新策略、分层统计或更细粒度诊断，可能需要继续补很多旁路逻辑。

## 低风险

1. **部分默认值偏保守，未必适合所有场景**
   - 位置：`config.py:24-53`
   - 问题：例如 `redundancy`、`direct_redundancy`、`udp_copy_interval_ms`、`tcp_loser_grace_ms` 都是通用默认值。
   - 影响：不是 bug，但不同线路质量下可能需要手工调参才能达到最佳效果。

2. **`README.md` 信息量较大，入门成本略高**
   - 位置：`README.md`
   - 问题：文档已经很完整，但新用户第一次看时会觉得模式、优先级、脚本行为比较多。
   - 影响：学习成本稍高，不过不影响核心功能。

3. **脚本命名和入口较多，初次使用容易混淆**
   - 位置：`scripts/start.sh`、`scripts/start-transparent.sh`、`scripts/start_udp.sh`、`scripts/start-relay.sh`
   - 问题：多个脚本分别负责不同模式，功能边界清楚，但命名上对新用户不够直观。
   - 影响：属于使用体验问题，不影响稳定性。

## 总结

- 这套代码已经是“可运行、可交付”的状态，核心风险不在功能缺失，而在**复杂并发场景下的可观测性和回归保护**。
- 如果后续要继续提升，优先顺序建议是：**配置校验 → 日志结构化 → 最小测试覆盖 → UDP/TCP 边界场景验证**。