refactor: 优化中间件架构并修复多个问题 (#108)

* refactor(core): 优化请求解析方法的语义分离

- 将 application/x-www-form-urlencoded 处理从 json_parse 移到 form_parse
- json_parse 现在仅处理 application/json 数据，移除不必要的 Serialize 约束
- form_parse 支持 multipart/form-data 和 application/x-www-form-urlencoded
- 实现统一缓存策略：WWW_FORM_URLENCODED 数据缓存到 json_data 字段
- 为 multipart/form-data 复用 form_data 缓存机制
- 添加完整的测试用例验证语义分离和缓存机制
- 更新 examples/form 示例使用正确的 form_parse 方法

BREAKING CHANGE: json_parse 不再支持 application/x-www-form-urlencoded
迁移指南：使用 form_parse() 替代 json_parse() 处理表单数据

* refactor(route): 统一路由处理架构，移除RootRoute结构

- 移除 RootRoute 结构体，将其功能完全融合到 Route 中
- 统一路由匹配逻辑，消除根路由和普通路由的人工区分
- 通过 configs 字段自然识别服务入口点，无需额外标志位
- 简化路由处理流程，减少代码重复和条件分支
- 保持所有原有功能和API兼容性
- 优化中间件层级管理和执行顺序
- 更新所有测试和示例以使用统一的Route结构

BREAKING CHANGE: RootRoute 类型已被移除，使用 Route::new_root() 替代

* fix(route): 修复路由匹配优先级和configs传递问题

修复了路由匹配逻辑中的优先级问题：
1. 空路径路由优先检查子路由，避免错误匹配
2. 非空路径路由优先匹配子路由，再检查自身处理器
3. 修复Server::serve中configs设置逻辑，避免覆盖已有configs
4. 确保路由匹配时正确传递configs信息
5. 移除调试信息，清理代码

解决了以下问题：
- 根路径/返回404而不是root_handler
- /api/v1/users返回hello处理器内容而不是user_handler
- 路由匹配优先级错误导致的功能异常

现在所有路由都能正确匹配到对应处理器，中间件层级管理正常。

* style(route): 清理调试信息和代码格式

移除所有调试用的 println! 语句，保持代码整洁：
1. 移除 handler_append.rs 中的调试输出
2. 移除 handler_match.rs 中的调试输出
3. 移除 route/mod.rs 中的调试输出
4. 移除 service/mod.rs 中的调试输出
5. 清理代码格式，移除多余的空行

保持核心功能不变，只是清理了调试信息。

* style(route): 进一步清理调试信息和优化代码格式

继续清理剩余的调试信息：
1. 移除 LayeredHandler 中的调试输出
2. 移除 handle_as_service_entry 中的调试输出
3. 移除 Route::call 中的调试输出
4. 移除未使用的循环变量 i
5. 优化代码格式和导入顺序

保持核心功能不变，进一步清理代码。

* fix(route): 修复空路径路由匹配问题并添加10层复杂路由benchmark

修复了路由匹配中空路径路由无法正确匹配的问题：
- 修复 last_matched 方法中空路径路由的子路由匹配逻辑
- 解决了 empty_path_edge_case_test、nested_empty_path_test 和 root_route_matching_test 三个测试失败的问题
- 确保空路径路由（如 Route::new('').get(handler)）能够正确匹配根路径 '/'

添加了全面的路由匹配性能benchmark：
- 创建10层深度嵌套路由的benchmark测试
- 包含静态路径、参数路径、中间件和混合类型的复杂路由测试
- 添加路由深度性能对比测试（3层、5层、7层、10层）
- 生成详细的性能测试报告

性能测试结果显示：
- 10层深度路由匹配性能约240ns，表现良好
- 参数解析开销约41%，中间件影响很小
- 性能随路由深度线性增长，可预测性强

修复了clippy警告：
- 将 assert_eq!(bool, true) 改为 assert!(bool)
- 将 assert!(false) 改为 unreachable!()

Closes #路由匹配问题

* fix(deps): 修复prost和tonic版本冲突问题

修复了gRPC示例中的依赖版本冲突问题：
- 将prost版本从0.14回退到0.13，与tonic 0.13兼容
- 解决了多个gRPC示例编译失败的问题
- 确保所有示例都能正常编译和运行

这个修复解决了以下错误：
- 'prost::message::Message' trait不匹配的问题
- tonic-build API兼容性问题
- 依赖树中多个prost版本冲突的问题

现在cargo check --all可以正常通过。

* fix(cookie): 修复CookieExt::cookies_mut方法中的unwrap panic问题

修复了CookieExt trait中cookies_mut方法的潜在panic问题：
- 在Request和Response的cookies_mut方法中添加了CookieJar初始化逻辑
- 当extensions中不存在CookieJar时，自动创建并插入新的CookieJar实例
- 避免了调用unwrap()时因为None值导致的panic

这个修复解决了cookies示例中的运行时panic问题：
- 修复前：调用res.cookies_mut()时如果CookieJar不存在会panic
- 修复后：自动初始化CookieJar，确保方法调用安全

测试验证：
- cookies示例现在可以正常运行，不再出现panic
- 所有单元测试通过
- clippy检查通过
- cargo check --all通过

* fix(merge): 解决Cargo.toml合并冲突并回退tonic版本

- 移除Git冲突标记
- 清理重复的依赖项定义
- 回退tonic相关依赖到0.13版本以保持API兼容性
- 为middleware_layered示例添加Apache-2.0许可证
- 更新Cargo.lock文件
- 格式化代码以符合rustfmt标准

Author: hubertshelley

Cargo.toml

@@ -1,11 +1,11 @@
 [workspace]
-members = ["silent", "examples/*", "benchmark"]
 default-members = ["silent"]
-resolver = "3"
+members = ["silent", "benchmark", "examples/*"]
+resolver = "2"
 
 [workspace.package]
-edition = "2024"
 authors = ["Hubert Shelley <hubertshelley@163.com>"]
+edition = "2024"
 homepage = "https://github.com/silent-rs/silent"
 license = "Apache-2.0"
 readme = "./readme.md"
@@ -14,24 +14,24 @@ version = "2.5.2"
 
 [workspace.dependencies]
 async-trait = "0.1.88"
-tokio = { version = "1", features = ["full"] }
-tonic = "0.14"
-prost = "0.14"
+chrono = "0.4"
+dlopen2 = {version = "0.8", features = ["derive"]}
+futures-util = "0.3"
+h2 = "0.4"
+headers = "0.4"
 http = "1"
-hyper-util = "0.1"
 hyper = "1"
-tower = "0.5"
-tonic-build = "0.14"
-tokio_wasi = { version = "1", features = ["full"] }
-tokio-stream = { version = "0.1", features = ["net"] }
-futures-util = "0.3"
+hyper-util = "0.1"
 once_cell = "1"
+parking_lot = "0.12"
+prost = "0.13"
+serde = {version = "1", features = ["derive"]}
+tokio = {version = "1", features = ["full"]}
+tokio-stream = {version = "0.1", features = ["net"]}
 tokio-tungstenite = "0.27"
+tokio_wasi = {version = "1", features = ["full"]}
+tonic = "0.13"
+tonic-build = "0.13"
+tower = "0.5"
 tracing-subscriber = "0.3"
-headers = "0.4"
-serde = { version = "1", features = ["derive"] }
-uuid = { version = "1", features = ["serde", "v4"] }
-parking_lot = "0.12"
-chrono = "0.4"
-dlopen2 = { version = "0.8", features = ["derive"] }
-h2 = "0.4"
+uuid = {version = "1", features = ["serde", "v4"]}

benchmark/README.md

@@ -0,0 +1,129 @@
+# Silent 路由匹配性能基准测试报告
+
+## 概述
+
+本报告展示了 Silent 框架中路由匹配功能的性能基准测试结果，特别关注10层复杂路由的匹配性能。
+
+## 测试环境
+
+- **框架版本**: Silent v2.5.2
+- **Rust版本**: 1.88.0
+- **测试平台**: macOS (darwin 24.5.0)
+- **编译模式**: Release (优化模式)
+
+## 测试场景
+
+### 1. 基础路由测试
+
+| 测试场景 | 平均耗时 | 性能表现 |
+|---------|---------|---------|
+| 简单路由匹配 | ~104 ns | 优秀 |
+| 嵌套路由匹配 | ~155 ns | 良好 |
+| 带中间件路由 | ~107 ns | 优秀 |
+| 多中间件路由 | ~105 ns | 优秀 |
+
+### 2. 复杂路由测试
+
+| 测试场景 | 平均耗时 | 性能表现 |
+|---------|---------|---------|
+| GET /api/v1/users | ~163 ns | 良好 |
+| POST /api/v1/posts | ~161 ns | 良好 |
+| GET /api/v1/posts/comments | ~172 ns | 良好 |
+
+### 3. 10层深度嵌套路由测试
+
+#### 3.1 静态路径路由
+
+| 测试场景 | 平均耗时 | 性能表现 |
+|---------|---------|---------|
+| 匹配最深路由 | ~233 ns | 良好 |
+| 匹配中间层路由 | ~202 ns | 良好 |
+| 不匹配路由 | ~235 ns | 良好 |
+
+#### 3.2 带参数路由
+
+| 测试场景 | 平均耗时 | 性能表现 |
+|---------|---------|---------|
+| 匹配最深路由（带参数） | ~329 ns | 良好 |
+| 匹配中间层路由（带参数） | ~227 ns | 良好 |
+
+#### 3.3 带中间件路由
+
+| 测试场景 | 平均耗时 | 性能表现 |
+|---------|---------|---------|
+| 匹配最深路由（带中间件） | ~231 ns | 良好 |
+
+#### 3.4 混合类型路由
+
+| 测试场景 | 平均耗时 | 性能表现 |
+|---------|---------|---------|
+| 匹配最深混合路由 | ~288 ns | 良好 |
+| 匹配中间层混合路由 | ~230 ns | 良好 |
+
+### 4. 路由深度性能对比
+
+| 路由深度 | 平均耗时 | 性能趋势 |
+|---------|---------|---------|
+| 3层路由 | ~171 ns | 基准 |
+| 5层路由 | ~192 ns | +12% |
+| 7层路由 | ~210 ns | +23% |
+| 10层路由 | ~240 ns | +40% |
+
+## 性能分析
+
+### 1. 路由深度对性能的影响
+
+从测试结果可以看出，路由深度对性能有一定影响，但影响相对较小：
+
+- **3层到10层**: 性能下降约40%
+- **每增加一层**: 平均增加约10-15ns
+- **线性增长**: 性能下降基本呈线性关系
+
+### 2. 参数解析的性能开销
+
+带路径参数的路由比静态路由慢约30-40%：
+
+- **静态路由**: ~233 ns
+- **参数路由**: ~329 ns
+- **性能差异**: 约41%的开销
+
+### 3. 中间件的影响
+
+中间件对路由匹配性能的影响很小：
+
+- **无中间件**: ~233 ns
+- **有中间件**: ~231 ns
+- **性能差异**: 几乎无影响
+
+### 4. 高负载测试
+
+1000个连续请求的处理时间约为225μs，平均每个请求约225ns，说明在高负载下性能保持稳定。
+
+## 优化建议
+
+### 1. 路由设计优化
+
+- **避免过深嵌套**: 建议路由深度不超过7层
+- **合理使用参数**: 参数路由比静态路由慢，应适度使用
+- **中间件优化**: 中间件对匹配性能影响很小，可以放心使用
+
+### 2. 性能优化方向
+
+- **路由树优化**: 可以考虑使用更高效的路由树结构
+- **参数解析优化**: 参数解析是主要性能瓶颈，可以进一步优化
+- **缓存机制**: 对于频繁访问的路由可以考虑添加缓存
+
+## 结论
+
+Silent 框架的路由匹配性能表现优秀：
+
+1. **基础性能**: 简单路由匹配在100ns左右，性能优秀
+2. **深度支持**: 10层深度路由仍能保持良好性能（~240ns）
+3. **功能完整**: 支持参数、中间件等高级功能，且性能影响可控
+4. **线性扩展**: 性能随路由深度线性增长，可预测性好
+
+总体而言，Silent 的路由匹配功能在保持功能完整性的同时，提供了优秀的性能表现，适合构建复杂的Web应用。
+
+## 测试代码
+
+详细的测试代码请参考 `benches/route_benchmark.rs` 文件，包含了各种复杂场景的基准测试。