rogee/quyun-v2
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: 更新路由参数约定，要求数字ID路径参数在@Router注解中显式声明类型以确保正确匹配

Browse Source
This commit is contained in:
Rogee
2025-12-29 15:44:25 +08:00
parent 9d598e7f9b
commit bdf20fb0c6
1 changed files with 4 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
backend/llm.txt
View File

@@ -30,7 +30,7 @@ This file condenses `backend/docs/dev/http_api.md` + `backend/docs/dev/model.md`
- DO NOT manually write route declarations (only `atomctl gen route`). - DO NOT manually write route declarations (only `atomctl gen route`).
- DO keep Swagger annotations consistent with actual Fiber route paths (including `:param`). - DO keep Swagger annotations consistent with actual Fiber route paths (including `:param`).
- MUST: route path parameter placeholders MUST be `camelCase` (e.g. `:tenantCode`), never `snake_case` (e.g. `:tenant_code`). - MUST: route path parameter placeholders MUST be `camelCase` (e.g. `:tenantCode`), never `snake_case` (e.g. `:tenant_code`).
- MUST: for numeric ID path params (`int/int64` like `tenantID/userID/orderID`), prefer Fiber typed params `:tenantID<int>` to avoid conflicts with static subpaths (e.g. `/orders/statistics`) and reduce ambiguous routing. - MUST: for numeric ID path params (`int/int64` like `tenantID/userID/orderID/id`), explicit declaration `:param<int>` is REQUIRED in `@Router` annotation to ensure proper route matching and constraints (e.g. `@Router /v1/users/:id<int> [get]`).
- MUST: when importing another HTTP module's `dto` package, the import alias MUST be `<module>_dto` (e.g. `tenant_dto`), not `<module>dto` (e.g. `tenantdto`). - MUST: when importing another HTTP module's `dto` package, the import alias MUST be `<module>_dto` (e.g. `tenant_dto`), not `<module>dto` (e.g. `tenantdto`).
- MUST: when creating/generating Go `struct` definitions (DTOs/requests/responses/etc.), add detailed per-field comments describing meaning, usage scenario, and validation/usage rules (do not rely on “self-explanatory” names). - MUST: when creating/generating Go `struct` definitions (DTOs/requests/responses/etc.), add detailed per-field comments describing meaning, usage scenario, and validation/usage rules (do not rely on “self-explanatory” names).
- MUST: business code comments MUST be written in Chinese (中文注释), to keep review/maintenance consistent across the team. - MUST: business code comments MUST be written in Chinese (中文注释), to keep review/maintenance consistent across the team.