网页应用部署前的配置核对
网页应用在本地开发模式正常，不表示生产首屏一定稳定。服务端渲染、静态资源缓存、客户端偏好、认证 Cookie 和部署环境变量都会影响最终页面。部署前的核对应围绕用户路径展开：首屏 HTML 是否与客户端首次渲染一致，资源是否来自正确版本，敏感配置是否留在服务端，失败时页面是否还有可用的基本状态。
先区分服务端与客户端可知的信息
服务端渲染时，只有请求中稳定可得的信息适合参与首次 HTML：公开路由参数、已经验证的会话状态，或明确传入的默认主题。localStorage、媒体查询、浏览器扩展和客户端模型预测在服务端不可知，若它们直接决定首屏 DOM 或 class，容易产生 hydration mismatch。更合适的做法是以稳定默认值渲染，水合后再读取客户端偏好并渐进更新。
隐藏整个页面直到水合完成能避免局部闪烁，却也可能让首屏空白。应只延后真正依赖客户端 API 的局部区域，并提供可访问的默认内容。suppressHydrationWarning只适合明确知道且局部可接受的差异，不能用来掩盖整个页面的渲染不一致。若出现警告，应找出数据来源和渲染时机，而不是简单压掉提示。
const [theme, setTheme] = useState(defaultTheme); useEffect(() => { const saved = window.localStorage.getItem("theme"); if (saved) setTheme(saved); }, []);这段逻辑让服务端与客户端第一次渲染使用同一个默认值。主题或个性化请求失败时，页面仍保留默认样式；如果结果来自模型或服务端接口，还要校验允许的 class 或配置值，不能把任意字符串写进 DOM。
缓存规则应与资源类型匹配
带内容哈希的静态 JS、CSS、字体或图片可以使用较长缓存，因为文件名变化会带来新版本；动态 HTML、用户资料和未带哈希的资源则需要不同策略。不要为所有.css或.js一概设置长期缓存，先确认构建产物与 CDN 的版本切换方式。发布后检查响应头、缓存命中和旧版本清理，避免用户同时拿到新 HTML 和旧脚本。
压缩、跨域和安全响应头也应按资源用途配置。跨域许可不能因为加载方便就开放给任意来源；Cookie 的域、路径、Secure 和 SameSite 属性要与实际登录流程一起测试。代理层应正确传递协议与主机信息，但不应盲目加入 WebSocket 或升级头给每个请求。
配置和密钥需要清晰边界
服务端密钥、数据库地址和第三方 token 不能被前端构建步骤读取。项目中约定的公开变量前缀只用于可安全展示的配置，例如公开 API 地址或功能标识；部署前可扫描构建产物和日志，检查是否意外包含密钥片段，但扫描结果不应打印真实内容。示例配置文件也只保留键名和无敏感说明。
AI 个性化或动态样式功能应通过服务端授权接口访问，确认用户身份、数据范围和缓存边界。服务不可用时，返回默认主题或关闭该增强功能，并在监控中记录脱敏的失败原因。不要让客户端直接持有模型供应商凭证来换取快捷实现。
用生产相近的条件验收
部署前在生产构建与预发域名下检查主要浏览器：是否出现 hydration 警告，首屏是否可读，登录与退出是否正常，静态资源是否来自预期版本，网络慢或 CDN 失败时页面怎样表现。动画可提升体验，但应尊重减少动态效果偏好并避免用无依据的 GPU 技巧掩盖性能问题。
保留部署版本、环境差异、验证结果与回退入口。配置核对不是一张只在上线当天看的清单；每次改变渲染方式、缓存、认证或个性化逻辑后，都需要重新验证这些边界。这样页面才不会把本地的偶然顺利带进生产的不确定性里。
