断点不生效需满足四个条件：用户具备debug connect session和debug any procedure权限；目标对象已添加调试信息；调试的是最新编译版本；断点位于实际执行路径上。
断点不生效，先看这四个硬性条件
断点点下去没反应，不是软件坏了，而是四个前提没满足：当前用户缺 DEBUG CONNECT SESSION 和 DEBUG ANY PROCEDURE 权限；目标对象（Procedure/Package Body）没带调试信息；你调试的不是最新编译版本；断点打在了不会执行的分支上（比如 IF FALSE THEN 里的语句）。任意一项缺失，F9 按下去就直接跑完，根本停不住。
排查顺序建议按这个来：
- 用 SYS 执行 GRANT DEBUG CONNECT SESSION, DEBUG ANY PROCEDURE TO your_user;
- 在 Object Browser 中右键目标对象 → 选 Add debug information（别信“已编译”就万事大吉，别人一重编译，调试信息就没了）
- 确保你在 Test Window 里调用的是刚加完调试信息、刚重新编译过的那个版本
- 把断点设在 BEGIN 后第一行，或明确会走的路径上，避开条件判断的死区
Test Window 启动调试前必须填对参数
右键存储过程 → Test 打开的窗口，不是用来“运行”的，是专为调试准备的入口。参数区域（右下角 Variables 面板）必须填全输入参数（IN 或 IN OUT），但输出参数（OUT）留空——PL/SQL Developer 会自动分配变量接收返回值。如果这里漏填、填错类型（比如把 NUMBER 当成字符串输），调试器可能直接报错退出，连断点都碰不到。
常见陷阱：
- DATE 类型参数别直接输 2026-07-27，得写成 TO_DATE('2026-07-27', 'YYYY-MM-DD')
- REF CURSOR 输出参数不用填，但要在调试过程中点击变量旁的放大镜图标才能看到结果集
- 多个参数时，顺序和声明顺序严格一致，不能靠名字自动匹配
F9 启动后卡在 BEGIN？这是正常起点
按 F9 或菜单 Debug → Start 后，光标停在测试代码的 BEGIN 行，不是 bug，是调试器在等你“单步进入”。这时候别急着点运行按钮（那个绿色三角），它会让整个过程一口气跑完。真正要做的，是按 Ctrl+N（Step Into）——它才会跳进你的存储过程体，断点才开始起作用。
几个关键操作对照：
- Ctrl+N：单步进入，遇到子过程/函数会跟进去
- Ctrl+O：单步跳过，把子过程当黑盒执行完再停
- Ctrl+T：跳出当前过程，回到调用处
- 鼠标悬停变量名可即时看值，但复杂结构（如嵌套表）得右键 → Add variable to Watches 才能展开
调试中变量值显示为空或报错，往往因为作用域问题
在 Package Body 里调试时，经常发现某个变量明明赋过值，Watches 里却显示 NULL 或报 PLS-00364。这不是数据丢了，而是变量声明在局部块（比如 DECLARE ... BEGIN ... END）里，超出作用域后调试器就不可见了。同样，包级变量（PUBLIC 或 PRIVATE）只有在 Package Body 内部才稳定可查，Specification 里声明的常量反而容易显示异常。
临时解决办法：
- 把关键中间变量提到过程级 DECLARE 段开头声明
- 调试时优先监控 IN/OUT 参数和过程入参，它们的作用域最稳
- 别依赖 Watches 面板自动刷新，每次单步后手动右键变量 → Refresh Value 更可靠
调试器本身不保存状态，每次重启调试都要重新加断点、重填参数、重开 Watches。真正的难点不在操作步骤，而在意识到：调试信息是临时附着在对象上的元数据，权限是会失效的，断点位置必须和实际执行流对齐——这些都不是“点一下就灵”的事。
