企业官网建设流程全解析

后台管理系统里最不起眼、也最容易翻车的模块，往往就是商品管理这一块。前面几个小节我们把商品列表、搜索、分页、删除都磨完了，剩下的就是最后两个动作：新增/编辑商品，以及提交成功后跳回商品列表页面。别看只有两个动作，真正动手写的时候你会发现，表单回显、接口区分、防重复提交、跳转后列表要不要刷新，每一步都藏着能让你调半天的小坑。我们用的是 React 技术栈，配 antd 表单和 react-router，这套组合在国内后台管理系统里几乎是标配，所以这篇讲的思路你直接抄过去基本能跑。这篇适合已经写过一点 React、正在做或者准备做后台管理系统商品模块的朋友，新手能看懂，老手可以对着自己的代码查漏补缺。接下来我按"设计思路、表单细节、提交实现、跳转同步、问题排查"这条线，把商品管理的收尾部分一次性讲透。

1. 商品管理收尾：新增/编辑与跳转的整体设计思路

商品模块做到最后这一步，其实是在做一个"闭环"——前面的列表负责"看"，现在要负责"写"。写完之后还得回到"看"的状态，并且看到自己刚写的成果。这个闭环看起来简单，但如果一开始思路没理清，后面会在跳转、刷新、数据同步这几个地方反复打补丁。所以动手之前，先把整体设计想清楚，比闷头写代码重要得多。

1.1 为什么把"新增"和"编辑"塞进同一个组件

我第一次做后台的时候，是老老实实写了两套页面：一个 AddProduct，一个 EditProduct。结果写完之后发现，两个页面的表单结构一模一样，字段、校验规则、布局几乎没有任何区别，唯一的差别是编辑页多了一步"回显接口数据"和提交时调的是修改接口。后来维护的时候更痛苦，产品经理说加个字段，我得改两个地方，改漏一个就出 bug。

所以现在我的做法非常固定：新增和编辑共用同一个页面组件，靠路由上有没有id参数来区分模式。这是后台管理系统里最经典的一种模式，叫"同构表单"。它的核心逻辑就一句话：

const { id } = useParams(); const isEdit = Boolean(id);

isEdit为true就是编辑模式，为false就是新增模式。这一个布尔值，后面会贯穿整个组件：标题文案、按钮文字、是否发起回显请求、提交时调哪个接口、提交成功后跳转时带什么提示，全都靠它来决定。这样做的好处很直接——只有一处维护成本，字段加减只改一次，逻辑分支集中在一个地方，不容易漏。

注意：区分模式的判断依据要统一。有的团队用路由id，有的用 query 参数，有的用 props 传mode。选一种就别混着用，否则后面某个入口传漏了参数，编辑页会被当成新增页，直接把老数据覆盖掉，这是生产事故级别的坑。

那为什么不用一个mode的 state 手动切换呢？因为路由参数是"可分享、可刷新、可后退"的。用户刷新编辑页，/product/edit/123这个 URL 还在，页面重新进来依然知道自己在编辑哪条数据。如果是靠内存里的 state，一刷新就全丢了，页面会退化成新增模式，体验非常差。

1.2 路由参数与模式判断：id 存在与否决定一切

路由这块我用 react-router v6 的写法，配置大概是这样的：

<Route path="/product/list" element={<ProductList />} /> <Route path="/product/add" element={<ProductEdit />} /> <Route path="/product/edit/:id" element={<ProductEdit />} />

你看，新增和编辑指向的是同一个组件ProductEdit，区别只是编辑路由多了:id这一段。这么配的好处是新增入口和编辑入口天然分开，菜单高亮、面包屑都好处理。列表页里点"编辑"，就navigate(\/product/edit/${record.id}`)；点"新增"，就navigate('/product/add')`。

拿参数的时候用useParams，注意它是返回字符串的：

const params = useParams(); const productId = params.id; // 编辑模式下是字符串，新增模式下是 undefined

这里有个小细节很多人忽略：id从 URL 里取出来永远是字符串。如果你的后端是用数字 ID 的，别忘了在调接口的时候转一下，或者干脆跟后端约定好接口同时接受字符串，省得类型对不上。我就遇到过后端用===严格比较number，前端传了字符串"123"，结果查不到数据的尴尬情况，排查了小半天。

还有一个判断时机的问题：isEdit的判断要放在组件渲染的早期，因为它决定了要不要发回显请求。合理的做法是放到useEffect里，依赖productId：

useEffect(() => { if (productId) { fetchDetail(productId); } }, [productId]);

依赖数组只放productId，不要放整个表单实例或者随渲染变化的对象，否则会造成无限请求。这个在下文讲回显的时候会再展开。

1.3 提交后的跳转策略：为什么用 navigate 而不是 window.location

提交成功后要跳回列表页，这个动作有两种写法：一种是window.location.href = '/product/list'，一种是navigate('/product/list')。我强烈建议用后者，也就是 react-router 提供的编程式导航。

原因在于window.location.href会触发整页刷新，也就是浏览器重新加载整个 SPA。这一步的代价是：所有内存状态清零、所有接口重新请求、页面白屏一瞬间、用户能看到明显的闪一下。而后台管理系统本身就是 SPA，整页刷新反而丢掉了 SPA 的优势。用navigate是路由级跳转，页面不刷新，状态还在，体验顺滑。

更重要的是，跳转的时候我们通常还想给用户一个反馈，比如"保存成功"。这时候可以借助路由 state 把消息带过去：

navigate('/product/list', { state: { refresh: true, message: '保存成功' }, });

列表页useLocation拿到这个 state，就能决定要不要重新拉一次列表，顺便弹个提示。用window.location的话这些都做不到，只能靠全局变量或者 storage，很别扭。

提示：navigate是 v6 的用法，v5 里对应的是history.push。如果你手上项目还是老版本，别照抄 API，思路是一样的，写法换了而已。

设计层面还有一个决策点：提交成功后到底跳不跳。有些团队的编辑页保存后不跳转，就停留在原地提示"保存成功"，方便用户继续改。我的经验是，新增商品保存后一定要跳回列表，因为用户需要确认"我加的东西进去了没有"；编辑商品保存后可以给两个选择，既可以停留也可以跳转，看你们的业务习惯。这篇按标题要求，统一按"提交后跳回列表"来处理，后面章节会给出具体实现。

2. 表单核心细节：回显、校验与状态管理

表单是整个提交环节的地基。地基没打好，后面接口调通了也会出现"改了这个字段那个丢了""校验拦不住脏数据"这类问题。这一章专门讲表单的三个核心难点：编辑态的数据回显、校验规则的设计，以及表单状态的管理方式。

2.1 受控与非受控：antd Form 的取值方式怎么选

antd 的 Form 组件提供了两套用法，一套是"受控"（每个字段自己维护 state，value+onChange），一套是"非受控"（交给 Form 实例统一管理，通过form.setFieldsValue和form.getFieldsValue读写）。后台管理系统的表单字段通常十几个起步，用受控写法会写一堆useState，维护成本极高，所以我基本都直接用Form 实例的非受控模式。

先拿实例：

const [form] = Form.useForm();

取值就用form.getFieldsValue()，可以传true拿到包括未触发校验字段在内的完整值：

const values = form.getFieldsValue(true);

赋值就用form.setFieldsValue({ ... })。这里有个非常关键的细节，也是我踩过的坑：setFieldsValue是合并不是覆盖。也就是说你只传{ name: 'abc' }，其他字段不会被清空。这在回显的时候是好事，但在"重置表单"的时候就是灾难——你以为传了个空对象就清空了，其实啥也没动。清空要用form.resetFields()。

表单提交的时候，antd 提供了onFinish回调，它只会在所有校验通过之后才触发，参数就是当前所有字段的值：

<Form form={form} onFinish={handleSubmit}> ... </Form>

所以真正的提交逻辑写在handleSubmit里就行，不用自己判断校验有没有过，antd 帮你把住了这道门。如果校验失败，会走onFinishFailed，一般用来把页面滚动到第一个出错的字段：

const handleFailed = (errorInfo) => { form.scrollToField(errorInfo.errorFields[0].name); };

注意：非受控模式下，表单值的唯一来源是 Form 实例，不要再去外面用 useState 存一份。两份状态一旦不同步，就会出现"界面上是新值，提交出去是旧值"这种灵异事件。要么全交给 Form，要么全自己管，切忌混用。

2.2 编辑态回显：把接口数据精准灌进表单

回显是编辑模式的核心动作。流程就是：拿到productId，请求详情接口，拿到数据，setFieldsValue灌进表单。听起来简单，但有几个坑必须提前避。

第一个坑是字段名对齐。接口返回的字段名和表单字段名经常不一致，比如接口是product_name（下划线），表单是productName（驼峰）。这时候你不是直接setFieldsValue(res.data)，而是要做一次映射。我一般会写一个转换函数：

const mapDetailToForm = (data) => ({ productName: data.product_name, price: data.price, stock: data.stock, categoryId: data.category_id, cover: data.cover, // 图片字段 });

这样接口怎么变，我只改这一处映射，表单内部字段名保持稳定，逻辑清晰。

第二个坑是图片、富文本这类非纯值字段的格式。比如封面图，表单里 antd Upload 期望的是fileList数组格式（每项有uid、name、url），而接口返回的往往就是一个 URL 字符串。回显的时候要手动转：

cover: data.cover ? [{ uid: '-1', name: 'cover.png', status: 'done', url: data.cover }] : [],

这个转换不做，编辑页的图片就是空的，用户以为图片没了，一保存还真就丢了。这种坑非常隐蔽，因为表单校验不会报错。

第三个坑是下拉框选项的异步回显。分类是一个下拉框，选项要从接口拉。如果详情回了categoryId: 5，但分类选项还没请求回来，setFieldsValue之后下拉框会显示成 value 数字（比如直接显示"5"）而不是分类名。解决办法是等选项数据到位再回显：

useEffect(() => { const init = async () => { await fetchCategories(); // 先拿选项 if (productId) { const detail = await fetchDetail(productId); form.setFieldsValue(mapDetailToForm(detail)); } }; init(); }, [productId]);

顺序很重要：先选项、后回显。反过来的话就会出现"闪一下数字再变成名称"的观感问题，虽然最终能对上，但体验不好。

2.3 校验规则：价格、库存、SKU 的约束怎么设计

后台表单的校验不能只是"必填"，还得管住业务逻辑。我挑几个典型字段说说规则怎么配。

价格字段，常见的规则是必填、数字、大于等于 0、最多两位小数。antd 的rules可以这样写：

{ name: 'price', label: '售价', rules: [ { required: true, message: '请输入售价' }, { type: 'number', min: 0, message: '售价不能为负数' }, { validator: (_, value) => { if (value === undefined || value === null) return Promise.resolve(); if (!/^\d+(\.\d{1,2})?$/.test(String(value))) { return Promise.reject(new Error('最多保留两位小数')); } return Promise.resolve(); }, }, ], }

这里用validator而不是正则写在pattern里，是因为type: 'number'和字符串正则容易打架。用自定义validator最灵活，逻辑想怎么写就怎么写。

库存字段除了非负整数，还得考虑上限。有些业务不允许库存超过 99999，那就加个max。SKU 编码通常要求唯一，这就涉及异步校验——需要调接口去查这个编码有没有被占用。antd 支持返回 Promise 的 validator，天然适配：

{ name: 'sku', label: 'SKU 编码', rules: [ { required: true, message: '请输入 SKU' }, { validator: async (_, value) => { if (!value) return; const res = await checkSkuUnique(value, productId); if (!res.unique) { throw new Error('该 SKU 已存在'); } }, }, ], }

checkSkuUnique里记得把当前商品 ID 也带上，因为编辑自己时，查到的是"自己占用自己"，应该算通过。后端判断时排除当前 ID 即可。

提示：异步校验会频繁触发（每次输入变化都可能触发），一定要做防抖，否则用户还没输完就发一堆请求。我一般给这类校验加 300~500ms 的延迟，或者改成"失焦时才校验"。antd 的validateTrigger可以指定触发时机，设成'onBlur'就很省心。

2.4 富文本与多图的联动处理：别让表单变脏

商品详情常见是富文本编辑器，商品图是多图上传。这两类字段和普通文本字段不一样，值不是简单字符串，处理不好会让表单数据"变脏"。

富文本的值通常是一段 HTML 字符串。提交前最好做一次清洗，比如去掉开头结尾的空标签、把相对路径的图片补成绝对路径。因为用户在编辑器里粘贴的内容可能带一堆乱七八糟的样式，直接存库以后前台渲染会很难看。

多图上传的字段值是一个数组，每个元素是一个文件对象。提交前要把它转成后端要的 URL 数组：

const images = (values.images || []) .map((file) => file.url || file.response?.url) .filter(Boolean);

.filter(Boolean)这一步很关键，能过滤掉上传失败或还没传完的空槽位，避免提交一堆undefined给后端。

还有个容易被忽略的点：图片上传和表单提交是两个独立的过程。用户点保存的时候，如果图片还在上传中（status: 'uploading'），你直接提交就会丢图。稳妥的做法是在提交前检查上传状态：

const uploading = (values.images || []).some((f) => f.status === 'uploading'); if (uploading) { message.warning('图片还在上传中，请稍候'); return; }

这几行代码帮我省了无数次"图片丢了"的售后问题。后台管理系统的体验，往往就是这些细节堆出来的。

3. 提交与修改接口的实操实现

表单搞定了，接下来就是把它变成真正的数据操作。这一章讲请求层怎么封装、新增和修改怎么区分、防重复提交怎么做，以及提交成功后如何干净利落地收尾。

3.1 请求层封装：统一错误处理的必要性

后台管理系统里，如果你每个页面都写一遍axios.post，然后每个地方都手写try/catch弹错误提示，代码会变得又长又重复。我的习惯是在项目里封一层请求模块，统一处理 baseURL、超时、token 注入、错误提示。这样做的好处是业务代码里只管拿数据，不用到处写错误处理。

一个精简版封装大概是这样：

import axios from 'axios'; import { message } from 'antd'; const request = axios.create({ baseURL: '/api', timeout: 15000, }); request.interceptors.response.use( (response) => { const res = response.data; if (res.code !== 0) { message.error(res.message || '请求失败'); return Promise.reject(new Error(res.message || 'Error')); } return res.data; }, (error) => { message.error(error.message || '网络异常，请稍后重试'); return Promise.reject(error); } ); export default request;

这里我做了一个约定：业务成功统一用code === 0表示（具体数字看你们后端）。拦截器里判断，非 0 就直接弹错误并 reject，业务层拿到的永远是干净的数据。这样写业务的时候：

const detail = await request.get(`/product/${id}`);

不用判断 code，直接用，非常清爽。

注意：错误提示最好在拦截器里做一次，别在业务层再弹一次，否则一个错误会弹两个 toast。我见过有人两处都写了message.error，用户看到两条相同的提示，一脸懵。

3.2 新增与修改：一个函数覆盖两种模式

前面说了，isEdit决定调哪个接口。我喜欢把它收敛到一个提交函数里，逻辑集中，改动只改一处：

const handleSubmit = async (values) => { setSubmitting(true); try { const payload = buildPayload(values); if (isEdit) { await request.put(`/product/${productId}`, payload); } else { await request.post('/product', payload); } message.success('保存成功'); navigate('/product/list', { state: { refresh: true } }); } catch (e) { // 错误提示已在拦截器统一处理，这里按需补充 } finally { setSubmitting(false); } };

buildPayload负责把表单值整理成后端要的结构：图片转 URL 数组、富文本清洗、字段名映射、去掉不需要的字段。把它单独拆出来，好处是方便写单元测试，也方便排查"提交上去的数据长什么样"这类问题。我调试接口的时候经常先在buildPayload里console.log一下最终 payload，很多字段对不上的问题一眼就能看出来。

关于方法是PUT还是PATCH，其实取决于后端的约定。PUT通常表示全量更新，PATCH是部分更新。后台商品编辑一般是把整份表单数据都提交上去，所以用PUT居多。这个不用纠结，跟后端对齐就行，前端改一个词的事。

3.3 防重复提交：loading 状态与按钮禁用

这是最容易被忽略、但线上最常出问题的点。用户点了保存，接口稍微慢一点，他等不及又点了一下，结果同一条商品被创建了两条——尤其新增场景，这个 bug 非常常见。解决办法就一个：提交进行中，把按钮禁掉。

实现上我用一个submitting状态控制按钮：

const [submitting, setSubmitting] = useState(false); <Button type="primary" htmlType="submit" loading={submitting} disabled={submitting} > {isEdit ? '保存修改' : '立即创建'} </Button>

htmlType="submit"让按钮直接触发表单的onFinish，同时loading和disabled双保险，loading给视觉反馈，disabled从行为上阻止第二次点击。

但这里还有个细节：光靠按钮禁用不够。如果用户用回车键提交，或者提交逻辑被别的地方触发，按钮的禁用拦不住。所以我还会在handleSubmit开头加一道锁：

const handleSubmit = async (values) => { if (submitting) return; setSubmitting(true); ... };

提示：setState是异步的，高频点击下submitting可能还没更新就进来第二次。要彻底稳，可以用useRef存一个同步的标志位。99% 的场景setState就够了，但对并发极其敏感的操作，用 ref 更保险。

3.4 提交成功的收尾：提示、跳转、状态重置

提交成功后有三件事要做，顺序和方式都有讲究。

第一件是给反馈。message.success('保存成功')是最基本的。反馈要即时，不能等跳转之后再弹，那样用户会觉得"我点了半天没反应"。所以提示放在跳转之前。

第二件是跳转。前面讲了用navigate，并且通过 state 把refresh标记传给列表页。跳转的同时，如果这个编辑页是被缓存过的（比如用了 keep-alive 类似的方案），记得把组件状态重置，避免下次进来看到上一篇的数据。

第三件是数据同步。这一件其实发生在列表页，就是收到refresh之后重新拉数据。这一块内容比较多，放到下一章细讲。

这里我说一个真实踩过的坑。有一次我把message.success放在了navigate之后，结果开发环境里跳转很快，提示一闪就没了，用户根本来不及看。后来改到跳转前，虽然只早了那么几十毫秒，但观感就完全不一样了。反馈一定要先于跳转，记住这个就行。

4. 跳回商品列表页面与数据同步

跳回列表这件事，表面上是navigate一行代码，但真正的难点在于"跳回去之后，列表得是最新的"。这一章把跳转的几种姿势、列表刷新的触发时机、以及多标签缓存下的数据一致性一起讲清楚。

4.1 navigate 传参：state 比 query 更适合传刷新指令

跳列表页的时候，我们可以带两类参数：query（URL 上看得见的，比如/product/list?refresh=1）和 state（URL 上看不见的，挂在 history 上）。它们有什么区别，用哪个更合适？

query 的好处是刷新页面后还在，坏处是会污染 URL，用户看到?refresh=1会觉得莫名其妙，而且一眼看去不知道干嘛的。state 的好处是干净、不影响 URL 观感，坏处是刷新页面后 state 会丢——但这恰好符合我们的需求，刷新意味着重新加载，本来就会重新请求，不需要额外的刷新指令了。

所以我的选择是state：

navigate('/product/list', { state: { refresh: true, from: 'product-edit' }, });

列表页接收：

const location = useLocation(); useEffect(() => { if (location.state?.refresh) { fetchList(); // 重新拉数据 // 用完清掉，避免返回时重复触发 navigate(location.pathname, { replace: true, state: {} }); } }, [location.state]);

这里有个关键操作：用完 state 之后要把它清掉（用replace: true重置）。为什么？因为如果不清，用户从列表点了详情再返回，location.state还是那个{ refresh: true }，会又触发一次刷新，没必要。用replace重置成空 state，就干净了。

4.2 列表刷新的三种触发时机与取舍

列表什么时候该刷新，其实有三种情况，得分开处理。

第一种是从编辑/新增页跳回来。这种情况必须刷新，因为数据变了。这就是上面 state 传refresh的用武之地。

第二种是在列表页内部操作，比如删除了一条、下架了一条。这时候没必要整页刷新，最优雅的做法是局部更新——从当前 list 数组里把那条删掉，或者改它的状态：

const handleDelete = async (id) => { await request.delete(`/product/${id}`); setList((prev) => prev.filter((item) => item.id !== id)); message.success('删除成功'); };

局部更新的好处是不闪屏、不重置分页、体验好，尤其当前页码不是第一页的时候，整页刷新会跳回第一页，用户还得重新翻，很难受。

第三种是保留分页和筛选条件。用户在第 3 页、筛选了某个分类，编辑完某条商品回来，理想情况是还停在第 3 页、筛选条件还在，只是数据更新了。如果无脑fetchList()重置了筛选，用户会骂人。所以我的做法是把分页和筛选参数外置到 URL query 或者状态管理里，刷新的时候带上这些参数一起请求。

为了兼顾"带回分页"和"数据新鲜"两个需求，跳转时可以顺手把列表的参数也带上：

navigate('/product/list', { state: { refresh: true }, });

列表页本身维护page、pageSize、filters，刷新的时候用当前的这些值去请求，用户的上下文就保住了。

注意：如果你用了状态管理（Redux、zustand 等），把列表的查询参数放进去，比放在组件 state 更稳。因为组件一旦卸载，state 就没了，跳回来就丢上下文。查询参数放全局，卸载重挂也能恢复。

4.3 数据一致性：缓存、多标签页与脏读的处理

这一节讲点进阶但不难的内容。后台管理系统里，列表数据可能被缓存（比如用了 React Query、SWR，或者自己手写的缓存）。缓存能减少请求、加快渲染，但也会带来"数据不新鲜"的问题。

假设你用了 React Query，从编辑页跳回来，切回列表页时它可能直接从缓存拿旧数据渲染，你看到的是修改前的状态。解决办法是提交成功后让相关缓存失效：

const queryClient = useQueryClient(); // 提交成功后 await queryClient.invalidateQueries({ queryKey: ['product-list'] });

缓存失效会触发后台重新拉取，用户看到的就是最新数据。这套机制比手动传refresh更优雅，如果你项目里已经在用数据请求库，优先用它自带的失效机制。

再说多标签页。用户可能在两个标签页都开着商品列表。在 A 标签改了商品，B 标签还显示旧数据。这种场景在后台管理系统里其实挺常见。彻底解决要靠跨标签页通信（比如监听 storage 变化、BroadcastChannel），但对大部分项目来说，保证当前标签页数据新鲜就够了，多标签一致性可以暂时不做，除非业务明确要求。

我自己的取舍是：优先保证"提交后立刻在本标签看到变化"，这是核心体验；多标签一致性属于加分项，等有空再补。别为了一个边缘场景搞一堆复杂机制，反而把主流程搞乱了。

5. 常见问题与排查技巧实录

前面讲的是"怎么写对"，这一章讲"写错了怎么查"。商品提交和跳转这块，出问题往往不好定位，因为牵扯表单、接口、路由好几层。我把这些年踩过的坑整理出来，你照着对号入座，能省不少时间。

5.1 编辑页数据回显失败或显示旧值

这是最高频的问题。表现是：进编辑页，字段是空的；或者显示的是上一个商品的名称。排查按这个顺序走。

先确认请求真的发出去了，而且带对了 id。打开 Network 面板，看详情接口有没有被调用，URL 里的 id 对不对。如果没发请求，八成是useEffect的依赖或者条件判断写错了，比如if (productId)里productId是undefined。

再看回显的时机。前面讲过，如果下拉框选项是异步的，回显必须在选项到位之后。如果接口数据回来了但setFieldsValue在选项之前执行了，下拉框就对不上。

如果显示的是上一个商品的值，那是状态没重置导致的。组件可能被复用了（同一个组件渲染不同 id），这时候要在productId变化时先form.resetFields()再回显：

useEffect(() => { form.resetFields(); if (productId) { fetchDetail(productId).then((d) => form.setFieldsValue(mapDetailToForm(d))); } }, [productId]);

先清空再填充，就不会串数据了。

5.2 提交成功了但列表没变化

这个问题的根源几乎都在"刷新没触发"。检查三处。

第一，跳转的时候 state 传了没：navigate('/product/list', { state: { refresh: true } })。有没有漏掉 state。

第二，列表页有没有正确地读 state 并触发刷新。location.state?.refresh拿到的是不是true。

第三，如果用了缓存，缓存失效了没。用了 React Query 之类的，别忘了invalidateQueries。

还有一种情况是数据其实更新了，但列表展示的是别的字段，你肉眼没看出来。这种情况多在 Network 里对比一下请求返回和页面渲染的字段，确认是"数据没更新"还是"展示没对齐"。

5.3 重复提交导致的脏数据

表现是列表里出现了两条一模一样的商品，或者库存被扣了两次。前面讲过防重复提交，这里补充几个容易漏的入口。

一是回车提交。表单里按回车会触发onFinish，如果你只在按钮上做了禁用，回车绕过了按钮的禁用。所以handleSubmit开头的if (submitting) return一定要有。

二是双击保存按钮。loading有延迟，极快双击可能第二次进来时submitting还没变。用useRef做同步锁最稳。

三是接口超时后的重试。有时候不是用户点的，是网络层自动重试导致的。这种情况要在后端接口做幂等（比如用唯一请求 ID），前端拦不住。跟后端约定好幂等机制，是最根本的解法。

5.4 常见问题速查表

把上面这些整理成一张表，遇到问题直接对照查，效率更高。

5.5 几条我踩坑后才悟出来的经验

最后分享几条没法从文档里学到、只能自己撞了才懂的经验。

提交逻辑和表单校验分开写。别在handleSubmit里再写一遍if (!values.name) return，那是 Form 的活。校验交给rules，提交只管业务。混在一起后，规则的唯一来源就分裂了，改一处漏一处。

payload 打印一次胜过猜十次。调接口对不上字段时，第一件事就是把最终 payloadconsole.log出来，对着接口文档一个一个比。我见过太多人对着代码空想，半小时没想明白，打印一下就秒解决。

跳转前先落数据，跳转后再刷界面。提交成功 → 提示 → 跳转 → 列表刷新，这个顺序别乱。先跳转再提示，提示会被路由切换打断；先刷新再跳转，用户在编辑页看到一个变了样子的列表，也很怪。

给每个接口调用留一个 catch 兜底。哪怕拦截器已经统一处理了错误提示，业务层最好还是有个finally保证 loading 能关掉。否则一旦请求抛异常，按钮就永远卡在 loading 状态，用户以为界面死了。这个坑我踩过不止一次，想起来都肉疼。

商品管理到这儿就算收尾了。回头看看，从列表到表单、从表单到接口、从接口到跳转，其实每一环都不复杂，难的是把它们的衔接处处理干净——回显别串数据、提交别重复、跳转别丢上下文、刷新别丢分页。这几件事做扎实了，整块商品管理的体验就立住了。真正做过后台的人都明白，功能能跑只是及格，衔接处不别扭才算合格。后续如果还要扩展，可以考虑给商品加个草稿箱、批量操作，或者把提交改成乐观更新，这些都是在现在这个骨架上顺手就能加的。