网站进入维护期后，最常见的争议不是“能不能改”，而是“这么小的改动要不要走变更”。边界不清，容易出现两种问题：一是把高风险操作当成顺手改，导致线上故障；二是把明显的小修小补也套上重流程，拖慢响应。建议用一条总原则判断：只要可能影响生产稳定、数据安全、权限合规、外部接口、核心用户路径或不可快速回滚，就必须走变更；反之，在授权范围内、可预览、可回滚、可记录的小修改，可以随手做。随手做不等于不留痕，而是“低风险快处理”；走变更也不等于复杂审批，而是“风险可控地改”。

一、随手可做的范围

随手做通常应同时满足：不碰数据库结构和业务数据；不改权限、安全和服务器配置；不改核心页面结构、URL和公共组件；影响面小；有预览或备份；可快速回滚；在维护合同或已授权范围内。典型包括：修正错别字、标点、联系电话和地址；替换同尺寸、已压缩的图片；在已授权栏目内发布、下架普通文章；修正失效的超链接；调整非核心页面的间距、颜色、字号等样式微调；更新非关键页面的简单文案；处理已被批准的日常内容备份和日志登记。此类操作也应记入维护日志，写明时间、内容、操作人和验证结果。

二、必须走变更的范围

必须走变更的，不是看“代码行数”，而是看风险。包括：数据库字段、索引、数据清洗、批量导入导出；用户、角色、权限、登录、支付、订单、会员等核心逻辑；接口参数、第三方SDK、短信邮件服务；域名、DNS、SSL、CDN、WAF、服务器、缓存和部署配置；依赖升级、公共JS/CSS、模板结构、路由和URL重写；核心页面SEO规则、统计埋点、隐私与合规相关调整；批量内容迁移、栏目结构调整；以及任何需要停机、可能不可逆或影响多端同步的修改。尤其要警惕“看似一行”的高风险操作，例如改Nginx配置、改全局脚本、改公共组件、改缓存策略、改数据库连接串，这些都应走变更。

三、执行建议

维护期可设三类：随手做、备案做、变更做。拿不准时按更高一级处理。变更应包含申请、影响评估、审批、实施窗口、备份、回滚方案、验证和记录；紧急故障可先止损，但必须事后补单、补记录、补复盘。客户或负责人应提前明确授权清单和禁止清单，避免“先改了再说”。

FAQ问答

Q1：改一个错别字也要走变更吗？

A：普通页面错别字、联系方式等低风险文案，在授权范围内可随手改，但需留维护记录；若涉及合同、服务价格、法律声明、隐私政策等敏感文案，应走确认或变更流程。

Q2：换一张图片算小修改吗？

A：同尺寸、同位置、已压缩且不影响布局和加载性能的图片可随手换；若涉及首页主视觉、核心活动页、大量图片或改变尺寸布局，应走变更或至少备案确认。

Q3：只改一行CSS/JS，能不能直接上线？

A：不能只看行数。若改的是公共样式、全局脚本、核心页面组件，可能影响全站，必须走变更；仅限单页非核心样式微调，才可随手处理。

Q4：紧急线上故障还要先审批吗？

A：可采用紧急变更：先止损、保留操作记录、通知负责人，事后补审批和复盘。紧急权限不能成为常规绕过流程的理由。

Q5：随手做需要记录吗？

A：需要。至少记录时间、修改内容、操作人、影响页面和验证结果。记录的目的不是增加负担，而是便于追溯、交接和判断是否应升级为变更。