wordpress的get_option()在长时ajax请求中会缓存选项值，导致后续并发请求（如取消操作）修改的选项无法被及时读取；需手动清除对象缓存才能获取最新值。
wordpress的get_option()在长时ajax请求中会缓存选项值，导致后续并发请求（如取消操作）修改的选项无法被及时读取；需手动清除对象缓存才能获取最新值。
在WordPress开发中，实现可中断的批量处理任务（如数据导入、定时同步等）是一个常见需求。典型做法是：前端发起一个长时AJAX请求执行batch操作，同时提供“取消”按钮触发另一个cancel_batch请求，通过共享状态（如wp_options表中的batch_state）协调二者。然而，开发者常遇到一个关键问题：取消请求成功调用update_option('batch_state', 'cancelled')后，主批处理循环中反复调用get_option('batch_state')仍返回旧值（如'running'），导致无法及时退出循环。
这并非WordPress环境隔离所致（每个AJAX请求确实在独立PHP进程/线程中运行），而是源于WordPress的对象缓存机制：get_option()默认会将选项值写入内存缓存（wp_cache_set()），后续同名调用直接从缓存读取，绕过数据库查询。而update_option()虽会更新数据库并刷新自身缓存，但不会主动通知其他正在运行的、已加载该键缓存的请求进程——尤其当批处理循环持续数秒甚至更久时，缓存早已过期却未被刷新。
正确解决方案：主动清理缓存
必须在每次检查状态前，显式清除对应缓存项。推荐使用wp_cache_delete()精准删除，而非全局wp_cache_flush()（后者会清空全部缓存，影响性能）：
add_action('wp_ajax_batch', 'my_ajax_batch_handler');
function my_ajax_batch_handler() {
// 初始化状态
update_option('batch_state', 'running');
// 示例数据（实际中可能来自数据库或API）
$values = range(1, 1000);
foreach ($values as $item) {
// 关键步骤：强制刷新 batch_state 缓存
wp_cache_delete('batch_state', 'options');
// 获取最新状态
$batch_state = get_option('batch_state', 'running');
// 检查中断信号
if ($batch_state === 'cancelled') {
error_log('Batch cancelled by user.');
wp_die('Batch cancelled.'); // 或返回 JSON 响应
}
// 执行单条处理逻辑（注意控制执行时间，避免超时）
process_single_item($item);
}
update_option('batch_state', 'completed');
wp_send_json_success(['message' => 'Batch completed.']);
}✅ 注意：wp_cache_delete('batch_state', 'options') 中的第二个参数 'options' 是缓存组名，必须明确指定，否则删除无效。这是WordPress对象缓存的标准约定。
补充最佳实践
- 避免无限循环与超时：长时PHP脚本易触发max_execution_time限制。建议在循环中加入set_time_limit(30)或使用wp_doing_ajax()配合心跳机制分片处理。
- 状态持久化增强：对于高可靠性场景，可结合数据库自增ID或transient（带过期）存储状态，并在cancel_batch中同时清理所有相关缓存。
- 前端协同设计：取消按钮应禁用并显示“取消中”，后端响应成功后再重置UI，避免用户重复点击。
通过精准缓存清理，即可确保多请求间的状态同步，让WordPress批量任务真正具备可控性与响应性。
