Files
2026Technology-Competition/data/demo-sqlfluff/reports/05_layout-review.md
T
范智鹏 c92249a044 docs: 归档 demo 工程样例与插件实测报告
- 新增三个 demo 工程(demo-eslint / demo-sqlfluff / demo-stylelint):各含 src/ 样例代码与覆盖率映射(run-coverage.mjs、coverage_map.json、stylelint_line_map.json)

- 归档各 demo 的插件实测导出报告(reports/):

  - demo-eslint:common.js / esm-demo.js / legacysyntax.cjs / typescript.ts 审查报告 + 覆盖率报告(292/292 条零偏差,126 种规则全覆盖)

  - demo-sqlfluff:11 个 SQL 样例审查报告 + 覆盖率报告(113/113 条零偏差,57 种规则全覆盖,含 JJ01 行号缺陷修复后的复测验证)

  - demo-stylelint:common.css / empty-source.css 审查报告 + 覆盖率报告(145/145 条零偏差,68 种规则全覆盖)
2026-08-25 22:00:19 +08:00

4.2 KiB

代码审查报告

文件: data\demo-sqlfluff\src\05_layout.sql 语言: sql 耗时: 176.0s 分析工具: sqlfluff


总计: 16 | 错误: 12 | 警告: 3 | 建议: 1

静态分析 · 12 个问题

  • 🔴 sqlfluff:LT01 L2 第2行:'*' 前应只有单个空格,实际有 2 个空格。 建议: 删除 SELECT* 之间的一个空格,改为 SELECT * FROM my_table;
  • 🔴 sqlfluff:LT02 L5 第5行:该行不应有缩进。 建议: 删除第5行行首的 4 个空格,使 SELECT 顶格书写。
  • 🔴 sqlfluff:LT05 L13 第13行:行太长(95 个字符超过 80 上限)。 建议: 建议缩短该列名,或在 sqlfluff 配置中调整 max_line_length;如果这是演示代码,也可以在该行使用 -- noqa: LT05 忽略此规则。
  • 🔴 sqlfluff:LT01 L19 第19行:左括号 '(' 前存在多余空白。 建议: 删除 SUM( 之间的空格,改为 SUM(amount)
  • 🔴 sqlfluff:LT06 L19 第19行:函数名 SUM 后面未紧接左括号。 建议: 将 SUM (amount) 改为 SUM(amount),函数名与左括号之间不要留空格。
  • 🔴 sqlfluff:LT02 L25 第25行:')' 前应换行且不应有缩进。 建议: 把 ) 移到下一行并顶格,即写成: SELECT id FROM my_table )
  • 🔴 sqlfluff:LT07 L25 第25行:WITH 子句的右括号应单独另起一行。 建议: 将 WITH 子句的 ) 放到 SELECT id FROM my_table 之后的独立行,且行首不要缩进。
  • 🔴 sqlfluff:LT08 L26 第26行:CTE 闭括号之后缺少空行。 建议: 在 )SELECT * FROM cte; 之间插入一个空行。
  • 🔴 sqlfluff:LT08 L32 第32行:CTE 闭括号之后缺少空行。 建议: 在 )SELECT * FROM cte; 之间插入一个空行。
  • 🔴 sqlfluff:AM02 L41 第41行:建议使用 UNION DISTINCTUNION ALL,不要单独使用 UNION。 建议: 若需要去重,改用 UNION DISTINCT;若不需要去重,改用 UNION ALL(通常性能更好)。
  • 🔴 sqlfluff:LT11 L41 第41行:集合运算符前后都应加换行。 建议: 将 UNION 放到单独一行,并让它前面和后面各有一行,例如: SELECT id FROM my_table UNION SELECT id FROM other_table;
  • 🔴 sqlfluff:LT12 L42 文件末尾:文件必须以一个单独的换行符结束。 建议: 在最后一行之后补一个换行符,并确保末尾没有多余空行。

AI 审查 · 4 条建议

  • 🟡 [AI] [design] long-identifier L13 过长的标识符影响可移植性与可维护性 第13行的列名本身接近80个字符,即使不考虑第13行的行长度限制,这个标识符也过长,可能超过部分数据库的标识符上限(如 MySQL 64、PostgreSQL 63、Oracle 128),并显著影响可读性与可维护性。 建议: 在建表/查询中改用简短、有意义的列名(如 long_total),并在应用层建立字段映射;若不能改名,请确认目标数据库的标识符上限并添加注释。
  • 🟡 [AI] [performance] redundant-distinct L35 DISTINCT 可能冗余 第35行 SELECT DISTINCT id FROM my_table; 如果 id 是主键或唯一列,DISTINCT 不会改变结果,却会引入额外的排序/哈希操作,增加查询开销。请确认 id 的唯一性;若已唯一,应去掉 DISTINCT。 建议: 若 id 已唯一,将 SELECT DISTINCT id 改为 SELECT id
  • 🟡 [AI] [bug] union-compatible-types L41 UNION 两侧字段类型需保证兼容 第41行通过 UNION 合并 my_table.idother_table.id。若两侧类型不同,数据库将进行隐式转换,可能造成转换错误、精度损失或性能下降。建议显式转换为同一类型后再合并。 建议: 根据实际类型显式转换,例如: SELECT CAST(id AS INTEGER) FROM my_table UNION SELECT CAST(id AS INTEGER) FROM other_table;
  • 🔵 [AI] [design] avoid-select-star L2 **避免使用 SELECT *** 第2、26、32行使用了 SELECT *。如果表结构日后新增列,结果集会随之变化,可能意外暴露敏感字段并增加不必要的数据传输。建议在正式查询中显式列出所需字段。 建议: 将 SELECT * 改为显式字段列表,例如只需要 id 时写 SELECT id