断点不生效是因为四个硬性条件未满足：用户缺少DEBUG CONNECT SESSION和DEBUG ANY PROCEDURE权限；目标对象未添加调试信息；调用的不是最新编译版本；断点设在不可执行路径上。
断点不生效，不是工具问题，而是四个硬性条件没满足。
调试前必须确认的四个权限与状态
PL/SQL Developer 的断点不会自动起作用，它依赖数据库端和客户端的协同就绪。任意一项缺失，F9 按下去就直接跑完：
-
DEBUG CONNECT SESSION和DEBUG ANY PROCEDURE权限必须由 SYS 或 DBA 显式授予当前用户（仅CREATE SESSION不够） - 目标存储过程或 package body 必须已通过右键 →
Add debug information加入调试符号；勾选Always add debug info when compiling后重新编译更稳妥 - 你在 Test Window 中调用的，必须是刚加完调试信息、刚编译过的那个版本；多人共用库时，别人一次
CREATE OR REPLACE就会清掉你的调试信息 - 断点必须设在实际执行路径上——比如
IF FALSE THEN ... END IF;内部、未触发的EXCEPTION分支、或被RETURN提前跳过的后续行，都不会停
从 Object Browser 进 Test Window 的正确流程
别手动写调用块，工具生成的测试框架能规避多数参数错误：
- 在左侧
Object Browser展开Procedures或Packages，找到目标对象，右键 →Test - 自动生成的窗口会列出所有
IN/IN OUT参数，OUT参数留空即可；务必填全非默认值的IN参数，否则可能因空值导致逻辑短路而跳过断点区域 - 填完参数后，不要点绿色“执行”按钮（Execute），而是点菜单栏
Debugger→Start Debugger，或直接按F9 - 此时窗口顶部状态栏显示
Debugging，且该 session 会被锁定（别人无法编译或执行该对象），这才是真正进入调试模式
单步执行时变量怎么盯住不丢
靠肉眼扫代码容易漏细节，关键变量必须主动监控：
- 执行到某行后想查
v_count值？直接在Variables区域下方输入框里敲v_count，回车就能实时显示（注意大小写敏感，且变量名必须在当前作用域内） - 多个变量要对比？打开
Debugger→Debugging Windows→Watches，添加v_input、p_result等，它们会持续刷新，比反复输入高效得多 - 代码高亮只标出“将要执行”的那行，不是“刚执行完”的那行——按
Ctrl+N（Step Into）后，高亮行才是下一步动作，别误判执行顺序 - 鼠标悬停变量名可即时看值，但复杂结构（如嵌套表、
REF CURSOR）得右键 →Add variable to Watches才能展开；REF CURSOR输出参数不用填，但要在调试中点击变量旁的放大镜图标才能看到结果集
DATE 和 NUMBER 类型参数填错是高频卡点
参数格式不对，调试器可能连断点都碰不到，直接报错退出：
-
DATE类型参数别直接输2026-07-27，得写成TO_DATE('2026-07-27', 'YYYY-MM-DD') -
NUMBER类型别输带引号的字符串，比如'123'，应填123 - 多个参数时，顺序和声明顺序严格一致，PL/SQL Developer 不按名字匹配，靠位置绑定
- 如果存储过程里有
SELECT ... INTO，记得提前确认对应表中有且仅有一条匹配数据，否则会抛NO_DATA_FOUND或TOO_MANY_ROWS直接中断调试流
最易被忽略的是：调试启动后光标停在测试块的 BEGIN 行，这是正常起点，不是 bug。这时候按 Ctrl+N 才会真正进入你的存储过程体——很多人卡在这一步，误以为调试失败，其实只是没“迈进去”。
