本条目讨论一个 Kotlin 代码模式中的隐蔽缺陷：同一功能有意从两个入口启动——一个是轮询循环（约每 200 毫秒检查一次进度，时间剩余量落在 1 到阈值的区间内即触发），另一个是条目真正结束时的回调。回调作为兜底入口，开头带有早退语句，避免两处同时启动功能。
问题在于这条早退让回调主体在多数时序下根本不会被执行：早退的写法有两种形式，一种直接判断已启动标志后返回，另一种把标志并入一长串条件合取式。无论哪种，常见情况下都是轮询路径先赢得竞争，回调主体只在少数时序下到达，因此仅加在回调里的条件几乎不会运行，且没有崩溃、警告或日志提示，功能照常运行仿佛新条件从未写过。
文中列出若干陷阱：只给回调加条件，表现为已发布的排除规则测试人员无法复现，只有当条目异常结束（跳过、条目过短、临近结束暂停）时才生效；只给轮询循环加条件，表现为功能几乎总被抑制，却在想排除的特定时序上仍然触发；手工把条件列表复制到两处，是最易复发的根源，两处相隔数百行的布尔链必须保持完全一致。
建议做法是把判定抽成单一谓词，两处共同调用；若两条路径确有差异（如轮询还需 isPlaying、正时长与阈值运算），共享部分放入谓词，各自追加自身特有机制，原则是任何排除条件都不能只存在于其中一条路径。另需注意早退只保证不会重复启动，不保证启动条件本身正确；轮询路径的阻塞日志需按条目节流，否则每秒五次输出会淹没其他日志；该形态同样出现在预取下一项、自动保存、分析上报、唤醒锁或前台服务释放、列表加载更多（滚动监听加数据末尾回调）等场景，凡在两个启动器之一顶部看到"已执行则返回"，其下所有条件都应视为可疑。
验证不能靠测试功能本身，因常见时序会掩盖缺陷，应采用结构性检查：搜索启动函数的所有调用点（如用 grep -n 检索），两处及以上即为该形态；逐一比对各调用点的守卫条件；增加记录由哪条路径启动的日志，让条目自然结束（轮询路径）并跳过进入很短的条目末尾（回调路径）分别验证，某路径从未出现于日志说明未测到而非不可能发生；新增排除条件时在调试构建中强制其为真，确认两条路径都会停止。