PHP中preg_match默认不匹配换行，需用/s和/m修饰符配合非贪婪模式及[sS]*?跨行提取存储过程体，并预清除注释、跳过字符串内分号，或改用状态机解析以应对嵌套与语法复杂性。
preg_match 无法匹配带换行/注释的存储过程体
PHP 的 preg_match 默认使用单行模式（/m 修饰符未启用），遇到含换行、多行注释（/* ... */）或嵌套括号的存储过程定义时，会提前截断或漏匹配。比如：CREATE PROCEDURE p1() BEGIN SELECT * FROM t; END 中的 BEGIN...END 块若跨行，基础正则根本抓不住。
解决方法是显式启用 /s（点号匹配换行）和 /m（^$ 匹配每行首尾）修饰符，并用非贪婪量词绕过注释干扰：
- 用
/(CREATEs+PROCEDUREs+w+[sS]*?ENDs*;)/is——[sS]替代.确保跨行，*?防止过度匹配到下一个END - 先用
preg_replace('//*.*?*//s', '', $sql)清除块注释（注意：不能清除行内--注释，需额外处理） - 避免用
.*匹配过程体，它会在遇到第一个;就停，而存储过程中;可能出现在字符串字面量里（如SET @msg = 'hello; world';）
匹配过程体时如何避开字符串字面量里的分号
存储过程中最坑的是：语句结束符 ; 和字符串内部的 ; 混在一起。正则无法真正“解析语法”，只能靠规避策略。
实用做法是分两步走：
立即学习“PHP免费学习笔记（深入）”；
- 先用
preg_match_all("/'([^'\\]|\\.)*'/", $sql, $strings)提取出所有单引号字符串（含转义），记录它们的起始/结束位置 - 再扫描原始 SQL 字符串，跳过所有被字符串区间覆盖的位置，只在“安全区域”找
;和END - 更轻量的替代方案：改用 MySQL 自带的
SHOW CREATE PROCEDURE proc_name获取干净定义，绕过正则解析——前提是已有过程名且有权限
不同数据库方言导致的正则兼容性断裂
MySQL 存储过程用 BEGIN...END，SQL Server 用 AS BEGIN ... END，PostgreSQL 用 $$ ... $$ 或 LANGUAGE plpgsql 块。一个正则不可能通吃。
实际项目中必须按目标数据库选型：
- MySQL：
/(CREATEs+PROCEDUREs+w+s*(.*?)s*(?:READS|MODIFIES)?s+SQLs+DETERMINISTICs+BEGIN[sS]*?ENDs*;)/is（注意DETERMINISTIC等可选关键字） - SQL Server：
/(CREATEs+PROCEDUREs+w+s+ASs+BEGIN[sS]*?END)/is，但得小心GO分隔符——它不是 T-SQL 语句，正则不该把它当终结符 - 别硬写“通用正则”，先明确你只跑在哪种 DB 上；否则宁可拆成多个分支
if ($db_type === 'mysql') { ... }
为什么不用 preg_match_all 直接提取所有过程定义
preg_match_all 看似方便，但它对嵌套结构完全无感。比如一个过程里调用了另一个过程，正则会把外层 BEGIN 和内层第一个 END 配对，导致截断。
真正鲁棒的做法是放弃纯正则，改用状态机扫描：
- 逐字符遍历，维护一个括号深度计数器（遇到
(加1，)减1） - 遇到
BEGIN且深度为 0 时标记为过程体起点 - 遇到
END且深度为 0 时才认为结束 - 同时跳过字符串和注释区（靠前面提到的字符串提取结果辅助判断）
正则适合做“粗筛”，比如从大段日志里快速捞出疑似 CREATE PROCEDURE 的行；真要完整提取定义，得上有限状态解析——这点容易被忽略，但恰恰是存储过程场景下最常翻车的地方。
