当使用 Symfony（尤其是 Sulu）框架进行 URL 访问日志记录时，若发现 lastInsertId() 返回的是已有记录 ID 且新行未实际插入，通常并非 SQL 或 ORM 逻辑错误，而是因 HTTP 请求被全站缓存（如 Sulu 的 HTTP 缓存或反向代理缓存）导致控制器根本未执行。
当使用 symfony（尤其是 sulu）框架进行 url 访问日志记录时，若发现 lastinsertid() 返回的是已有记录 id 且新行未实际插入，通常并非 sql 或 orm 逻辑错误，而是因 http 请求被全站缓存（如 sulu 的 http 缓存或反向代理缓存）导致控制器根本未执行。
在典型的 Sulu + Symfony 架构中，页面级 HTTP 缓存（例如通过 sulu_http_cache 或 Symfony 的 HttpCache）会将整个响应直接返回给客户端，跳过控制器逻辑执行。这意味着你写在控制器中的数据库插入代码（如 INSERT INTO custom_tracking ...）根本不会运行——所以既没有新记录生成，lastInsertId() 获取的自然也不是本次操作的 ID，而是上一次真实执行插入时留下的旧值（甚至可能来自其他请求）。
你当前的代码逻辑本身是正确的：
const INSERT_TRACKING_SQL = "
INSERT INTO `custom_tracking` (`utidId`, `url`, `urlParams`, `time`)
VALUES (:utidId, :url, :urlParams, NOW())
";
$conn = $entityManager->getConnection();
$stmt = $conn->prepare(self::INSERT_TRACKING_SQL);
$stmt->bindValue(':utidId', $utid_db_id);
$stmt->bindValue(':url', $url);
$stmt->bindValue(':urlParams', $urlParams);
$stmt->execute();
$tracking_id = $conn->lastInsertId(); // ✅ 此处仅在控制器真实执行时才有效
但前提是：这段代码必须被实际调用。若请求命中了 Sulu 的页面缓存（如 <cache></cache> 标签启用、或 Response 设置了 public + max-age），控制器将被完全绕过，SQL 永远不会执行。
✅ 推荐解决方案（按优先级排序）：
-
禁用该路由的 HTTP 缓存（最直接）
在控制器方法上添加#[Cache(maxage: 0, smaxage: 0, public: false)]（Symfony 6.3+）或在 YAML 路由配置中设置：# config/routes.yaml tracking_log: path: /_log/visit controller: App\Controller\TrackingController::logVisit methods: ['POST'] options: cache: false # Sulu 会忽略此路由的缓存同时确保响应头明确禁止缓存：
public function logVisit(Request $request): Response { // ... 插入逻辑 return new Response('', Response::HTTP_NO_CONTENT) ->setPublic(false) ->setMaxAge(0) ->setSharedMaxAge(0) ->headers->addCacheControlDirective('no-store'); } -
前端异步上报（更健壮，推荐用于埋点场景）
将日志采集移至客户端，通过 Fetch/AJAX 触发独立、无缓存的轻量接口：<script> fetch('/_log/visit', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ utidId: {{ utid_id|json_encode }}, url: window.location.href, urlParams: new URLSearchParams(window.location.search).toString() }), cache: 'no-cache' // 强制不走浏览器缓存 }); </script>对应后端接口需严格禁用缓存，并建议使用
POST方法（默认不可缓存）。
⚠️ 注意事项：
- 不要依赖
GET请求记录日志（易被 CDN/浏览器缓存）； - 避免在模板中直接嵌入 PHP 日志逻辑（Sulu Twig 缓存会使其失效）；
- 若必须服务端触发，请确认
kernel.debug = true时行为是否一致——调试模式下缓存常被禁用，容易掩盖问题； - 使用
bindValue()替代bindParam()（你代码中已用bindParam，但若变量后续被修改可能引发意外，bindValue更安全）。
总结：这不是数据库或 PDO 的问题，而是典型的「缓存穿透缺失」问题。解决核心在于确保日志逻辑所在的 PHP 执行上下文真实发生。优先采用独立无缓存接口 + 前端触发，兼顾可靠性与性能；若必须服务端同步记录，则务必关闭对应路由的全部层级缓存（Sulu → Symfony → Nginx/Varnish）。
