广告配置后台很少只是一个增删改查页面。一条广告计划可能包含素材、投放位置、时间范围、落地页、定向信息和上线状态，运营人员还需要随时筛选、查看、调整和终止投放。
这类系统使用阿里飞冰 ICE 作为 React 后台项目基础，可以快速建立布局、路由和常用管理页面结构。框架提供的是工程起点，而业务能否长期维护，仍取决于列表、表单和状态流转是否有清晰边界。
管理后台先围绕任务组织页面
广告管理通常包含几类主要任务：
查询：按广告位、状态、时间和关键词定位计划创建：填写素材、投放策略和承接页面审核或上线：检查数据后改变计划状态调整：修改时间、素材或配置监控：查看当前运行状态和异常信息因此页面结构可以按任务划分，而不是把所有操作堆在一个表格中：
广告计划列表页 -> 查询区域 -> 表格和批量操作 -> 新建/编辑抽屉 -> 详情与操作记录ICE 项目中，布局和基础页面模板能够保持统一；具体广告业务模块则使用 React 组件继续分层。
查询状态和编辑状态不要混在一起
列表查询参数会影响当前数据集，编辑表单只影响一条计划的草稿。如果二者使用同一组页面状态，关闭编辑弹层时容易错误重置列表，或者刷新列表时把尚未提交的输入覆盖。
function AdPlanPage() { const [query, setQuery] = React.useState({ keyword: "", positionId: "", status: "", page: 1 }); const [editingId, setEditingId] = React.useState(null); const [editorVisible, setEditorVisible] = React.useState(false); return ( <Page> <AdQueryForm value={query} onSearch={setQuery} /> <AdPlanTable query={query} onEdit={id => { setEditingId(id); setEditorVisible(true); }} /> <AdPlanEditor id={editingId} visible={editorVisible} onClose={() => setEditorVisible(false)} /> </Page> );}列表页只保存“正在查看什么”；编辑器负责“正在修改什么”。保存成功后再通知列表刷新，这样页面关系更容易理解。
表单的复杂度来自业务约束
广告计划中的字段通常不是彼此独立的：
- 选择广告位后，素材尺寸和格式会随之变化。
- 投放开始和结束时间必须满足有效区间。
- 使用 Lynx 页面或 H5 承接时，页面资源和落地配置字段不同。
- 上线中的计划是否允许修改，需要符合状态规则。
可以将校验分成基础校验与业务校验：
function validatePlan(form) { const errors = {}; if (!form.name) errors.name = "请输入计划名称"; if (!form.materialId) errors.materialId = "请选择素材"; if (form.startTime >= form.endTime) { errors.endTime = "结束时间需要晚于开始时间"; } if (form.renderType === "lynx" && !form.lynxPageId) { errors.lynxPageId = "请选择 Lynx 页面"; } return errors;}基础表单组件可以通用，具体约束则应留在广告计划领域内部，而不是散落在页面点击事件中。
状态变更应被看作流程操作
上线、下线和暂停不是简单改一个字段。操作前可能需要校验计划完整性，操作后需要刷新列表、记录失败原因，并避免用户重复提交。
async function changePlanStatus(planId, nextStatus) { setSubmitting(planId); try { await adService.changeStatus(planId, nextStatus); message.success("状态已更新"); reloadList(); } catch (error) { message.error(error.message || "操作失败，请重试"); } finally { setSubmitting(null); }}将状态操作封装成单独能力，能够让表格、详情页甚至批量操作复用相同规则。
从早期后台页面到 React 后台框架
早期使用 AngularJS 开发配置后台时，控制器、服务和指令已经能够组织数据驱动页面。到了 React 与 ICE 的项目中，变化不仅是框架语法：
- 页面布局、路由和工程脚手架更容易标准化。
- 业务组件可以围绕明确输入输出组合。
- 表单、列表和操作流程能够更细粒度拆分。
- 多个后台模块更容易共享一致的交互和视觉约定。
框架不会自动解决广告业务的复杂性，但它能够把重复的基础工作固定下来，让开发重心回到投放状态、配置约束和操作可靠性这些真正影响业务的问题上。