问题现象：分类挂了大量商品后，点击保存长时间转圈甚至504。提高max_execution_time只能延后失败，真正要定位保存请求卡在哪一段。
| 阶段 | 实际操作 |
|---|---|
| 复现 | 保存前记录分类ID、关联商品数量、是否修改URL Key，以及请求开始时间。查看Nginx access、PHP-FPM slowlog和exception.log，用相同时间定位最后执行的方法。 |
| 取证 | 只改分类名称能成功、改URL Key失败，重点统计该分类现有url_rewrite数量并检查重复request_path；不要先批量删除全站重写。 |
| 修复 | 不改URL也超时，则检查请求是否提交了完整商品选择网格，以及自定义Observer是否在catalog_category_save_after再次调用save。移除递归保存，把批量关联改为Repository/资源模型的一次性更新。 |
| 回归 | 先在预发布复制该分类并验证修复。生产处理冲突重写时，只删除明确属于目标entity且可重新生成的记录，保留备份并重建catalog_url。 |
可直接执行的检查
SELECT COUNT(*) FROM catalog_category_product WHERE category_id=:category_id;
SELECT request_path,store_id,COUNT(*) c FROM url_rewrite WHERE entity_type='category' AND entity_id=:category_id GROUP BY request_path,store_id HAVING c>1;
rg -n 'catalog_category_save_(before|after)|->save(' app/code
bin/magento indexer:reindex catalog_category_product catalog_product_category catalog_url通过标准：分别保存名称、描述、URL Key和100个商品关联；每项都在代理超时前完成，前台旧URL按配置跳转，新URL返回200且无重复重写。
若必须修改上万商品关联，优先拆分后台操作或使用受控批处理，不要让一个HTTP请求承担全部工作。
