<p>有效注释必须紧跟参数声明后用/ /包裹并对其，逻辑块前写目的性说明，动态SQL和CTE需注明结构与意图，IF/CASE分支内解释决策依据，缩进与换行须严格规范以支撑可读性。</p>

参数声明后必须加/* */块注释说明业务含义

很多人把参数注释写在行尾或堆在存储过程开头，结果三个月后自己都看不懂@Status到底是0=全部还是0=禁用。真正有效的注释只有一种位置：紧跟在每个参数声明后面，用/* */包裹，且与参数对齐。

• @StartDate DATE, /* 起始日期，含当日，格式 YYYY-MM-DD */
• @Status TINYINT /* 0=全部, 1=已发货, 2=已取消 */
• 别用--写长注释——SSMS折叠时会丢失上下文，/* */才能稳稳锚定在参数旁
• 如果参数名本身模糊（如@flg），光靠注释也救不回来，得先重命名

关键逻辑段前必须用/* */写目的性注释

“此处计算用户7日留存”比“计算留存率”有用，“含去重与时间窗口校验”比“做聚合”明确。人脑不是编译器，不关心你怎么算，只关心你为什么这么算、要解决什么业务问题。

• 注释必须出现在逻辑块之前，不是之后——眼睛扫下来第一眼就得知道这段干啥
• 避免泛泛而谈：“数据处理”“业务逻辑”这类词等于没写
• 涉及动态SQL时，注释里必须写出最终拼出的字符串结构，例如：/* 拼接 WHERE CustomerID IN (1,2,3) AND Status = 1 */
• CTE块开头也要加注释，比如：WITH ActiveOrders AS /* 过滤近30天未取消订单 */

IF/CASE分支内部必须解释意图，不能只写条件

看到IF @RetryCount > 3，没人知道是发告警、降级还是直接抛错。分支里的注释不是解释语法，而是补全决策依据。

• 在THEN和ELSE块开头各加一行/* 重试超限，触发人工介入流程 */这类说明
• 多个WHEN分支之间用空行隔开，每段/* 处理订单状态为'待支付'的场景 */
• 别把注释塞进IF语句同一行——缩进错位后极易被忽略
• 嵌套IF超过两层时，建议拆成独立存储过程，注释救不了失控的嵌套

缩进和换行规则比语法更影响可读性

SQL Server不靠缩进执行，但人靠缩进理解层级。顶格写的三层子查询+JOIN，等于强迫别人手动数括号。

• SELECT列表每列一行，函数和别名也单独成行：COUNT(*) AS OrderCount
• FROM和所有JOIN左对齐，ON条件缩进一层，多条件换行不逗号分隔
• WHERE、GROUP BY、HAVING、ORDER BY必须各自独占一行
• CTE的WITH块整体缩进4空格，AS (后换行，)单独成行并与WITH对齐

最常被忽略的是注释和缩进的协同：哪怕注释写得再准，缩进乱了，人眼就找不到它该对应哪一段逻辑。格式不是装饰，是阅读路径的路标。