20260908170359

code/fms/开发规范.md

@@ -12,6 +12,18 @@
 
 5. **当前系统按内部 ERP 处理** — 默认使用场景是已登录的内部用户和受控网络。当前需求阶段不额外引入复杂的安全防护层、SQL 注入专项改造或前后端重复校验；除非用户明确提出，不因安全假设新增接口、中间层或配置系统。查询条件可以信任前端传入，后端重点完成查询、分页和数据格式转换。
 
+6. **SQL 驱动优先** — 本系统是 SQL 驱动的内部 ERP。能通过 SQL 完成的查询、关联、过滤、排序、分页、聚合、权限过滤和数据范围过滤，优先在 SQL 层完成，不在业务代码中加载大量数据后再处理。
+
+7. **优先使用配置驱动的动态 SQL** — 模块、字段、查询条件、排序、字段权限和数据范围等存在于表结构中的规则，应由通用查询逻辑读取配置并动态生成 SQL。动态部分只允许来自受控的模块元数据、字段定义、操作符白名单和权限配置；业务值使用参数传递，不把任意前端字符串直接拼接为 SQL。
+
+8. **动态配置不等于任意 SQL** — 配置可以决定查询哪些表、字段和条件，但必须经过现有元数据和业务规则校验。不得为了追求灵活，把整段未审查的 SQL 保存到配置表并直接执行；确需使用原生 SQL 时，应限制在明确的模块或服务边界内。
+
+9. **固定 SQL 只用于稳定且明确的特殊逻辑** — 当 SQL 由固定业务规则组成，或动态生成会明显降低可读性、性能和可维护性时，可以使用固定 SQL。固定 SQL 应保持通用，不为单个页面或单个用户复制一套接口和查询。
+
+10. **权限过滤以后端 SQL 为准** — 前端可以根据权限隐藏菜单、按钮和字段，但最终的模块操作权限、字段可见/可查询/可导出权限以及数据范围，必须在后端查询或写入 SQL 中落实。用户个性化配置只能调整布局，不能放宽权限。
+
+SQL 驱动的实现应优先复用通用查询、保存和权限计算逻辑。模块之间的差异通过 `s_module`、`s_field`、`s_field_view`、`s_field_edit`、`s_field_query`、权限表和数据范围表配置；新增模块或字段时，优先增加配置数据，不复制一套模块专用 SQL。动态 SQL 只动态替换受控的标识符和条件结构，参数值仍单独传递。
+
 ## 前端代码风格
 
 1. **少用语法糖** — 优先使用直白、易读的写法，避免为了炫技而使用语法糖，可读性优先。