project-issues.md 4.9 KB
mynetspeeder 项目问题清单
说明：本文只做项目体检，不修改代码。按“高风险 / 中风险 / 低风险”排序，优先列出最可能影响稳定性、排障和后续维护的问题。
高风险
配置缺少严格校验
- 位置：
config.py:54-89 - 问题：
Config.load()直接读取 JSON 并套默认值，缺少字段类型、取值范围、必填项的统一校验。 - 影响：配置写错后往往不是启动时立即失败，而是运行一段时间后才在网络路径、重连或统计逻辑里暴露，排查成本高。
- 位置：
并发状态机复杂，容易出现隐性竞态
- 位置：
relay_client.py:49-235、transparent_edge.py:197-847、socks_edge.py:241-680 - 问题：连接、会话、winner 选择、重连、关闭清理都依赖大量异步任务和共享状态。
- 影响：在高并发、短连接、抖动网络、对端异常关闭时，可能出现“会话已关但任务还在跑”“winner 已切换但旧路径未及时收敛”等边界行为。
- 位置：
异常处理偏宽，真实错误容易被吞掉
- 位置：
relay_client.py、relay_server.py、transparent_edge.py、socks_edge.py - 问题：项目里大量使用
except Exception，部分分支只做pass或简单打印。 - 影响：服务能尽量不中断，但很多根因不会被结构化记录，后续定位问题主要依赖人工翻日志。
- 位置：
日志格式强依赖，汇总结果脆弱
- 位置：
cli.py:18-295 - 问题：
summary通过正则解析运行日志，完全依赖日志文本格式稳定。 - 影响：只要日志文案略有调整，统计结果就可能漏算或错算，适合临时分析，不适合作为长期可靠报表源。
- 位置：
中风险
缺少自动化测试覆盖
- 位置：仓库当前未见测试文件
- 问题：网络代理、中继、UDP 竞速、透明接管这类逻辑对回归特别敏感，但目前没有明显的单测或集成测试保护。
- 影响：改动一处逻辑，可能在另一路径上引入回归，尤其是重连、关闭、UDP 分包和 winner 收敛场景。
日志输出偏“人读友好”，不够机器化
- 位置：
relay_client.py、relay_server.py、transparent_edge.py、socks_edge.py - 问题：当前更多是
print(...)风格输出，缺少统一级别、字段、结构化上下文。 - 影响：排障时可以看，但想做持续监控、指标采集、告警联动会比较费劲。
- 位置：
UDP 路径语义较复杂，文档和实现容易产生认知偏差
- 位置：
README.md、scripts/start-transparent.sh、socks_edge.py、transparent_edge.py - 问题：当前有“UDP 透明接管”和“显式 SOCKS5 UDP ASSOCIATE”两套入口，且
socks_port > 0时会优先走 SOCKS 入口。 - 影响：如果用户只看配置字面意思，容易误以为 UDP 透明和 SOCKS UDP 会同时生效，实际行为需要结合启动脚本理解。
- 位置：
重连与健康检查阈值偏经验化
- 位置：
config.py:31-38、relay_client.py:60-75、scheduler.py:24-58 - 问题：重连间隔、ping 超时、open timeout、probe timeout 都是经验值。
- 影响：在不同网络质量下，过于激进会误判，过于保守会拖慢故障恢复。
- 位置：
统计与调度逻辑耦合在一起，后续可维护性一般
- 位置：
scheduler.py、cli.py - 问题：调度器和状态统计、探测输出、汇总逻辑之间复用不多，更多是“当前能用”。
- 影响：未来如果要增加新策略、分层统计或更细粒度诊断，可能需要继续补很多旁路逻辑。
- 位置：
低风险
部分默认值偏保守，未必适合所有场景
- 位置：
config.py:24-53 - 问题：例如
redundancy、direct_redundancy、udp_copy_interval_ms、tcp_loser_grace_ms都是通用默认值。 - 影响：不是 bug，但不同线路质量下可能需要手工调参才能达到最佳效果。
- 位置：
README.md信息量较大，入门成本略高- 位置：
README.md - 问题：文档已经很完整，但新用户第一次看时会觉得模式、优先级、脚本行为比较多。
- 影响：学习成本稍高，不过不影响核心功能。
- 位置：
脚本命名和入口较多，初次使用容易混淆
- 位置：
scripts/start.sh、scripts/start-transparent.sh、scripts/start_udp.sh、scripts/start-relay.sh - 问题：多个脚本分别负责不同模式，功能边界清楚，但命名上对新用户不够直观。
- 影响：属于使用体验问题，不影响稳定性。
- 位置：
总结
- 这套代码已经是“可运行、可交付”的状态，核心风险不在功能缺失，而在复杂并发场景下的可观测性和回归保护。
- 如果后续要继续提升，优先顺序建议是：配置校验 → 日志结构化 → 最小测试覆盖 → UDP/TCP 边界场景验证。