企业官网建设流程全解析

1. 先把“8+1”到底是什么搞清楚

拿到“实现官网demo（8+1）”这个标题，我第一反应不是去开编辑器，而是先把它掰开揉碎：这个“8+1”到底指什么？

从我接触过的实际项目来看，最常见的情况是：官网里有8个常规页面，外加1个特殊页面。常规页面基本跑不出这几个：首页、产品/服务列表页、产品详情页、关于我们、新闻资讯列表页、新闻详情页、联系我们、FAQ帮助页。特殊页面就五花八门了，可能是落地页、活动专题页、404个性页，也可能是需要特殊交互的演示页（比如在线Demo体验页、交互式计算器页）。

还有一种情况，这个“8”不是页面数量，而是模板组件数量。“8+1”意思是8个通用模块组件加1个核心业务模块。比如电商官网：导航、Banner轮播、商品列表、商品详情、购物车、订单结算、用户中心、文章模块 —— 这算8个通用模块，最后加一个支付回调模块。这个解释在实际开发里也特别常见。

所以拿到需求第一件事，先确认“8+1”是对外的页面数量，还是对内的功能模块数量。这个不分清楚，后面整个方案都可能跑偏。你可以直接问需求方一句：“这8个是用户能看到的页面，还是后台能配置的模块？”大多数情况下对方听到这个问题会愣一下，然后告诉你真实意图。这不是你理解能力不行，而是这个表述本身就是圈内“黑话”，默认做官网的人能自己领会。

基于我个人的项目经验，这篇文章我按“8个标准展示页面 + 1个交互特色页面”的官网Demo来拆解，因为这是个人接单、小团队交付时出现频率极高的一种组合，也最考验整体规划能力。8个标准页解决“官网完整”的问题，1个特色页解决“官网亮眼”的问题。

2. 动手前必须想清楚的三层设计

确定好“8+1”的具体含义之后，别急着写代码。我见过太多项目死在中途，不是技术不行，而是前期没想清楚就开干。官网Demo虽然看起来不复杂，但它是一个完整的“内容系统”，不是几个页面拼在一起就完事。动手前有三层设计必须过一遍脑子。

2.1 信息架构层：用户凭什么留在你的官网

信息架构是官网的骨架，它决定了用户从哪个入口进来、按什么路径浏览、最终去哪里留下联系方式或完成转化。一个好的官网信息架构，核心逻辑是“用户脑中的问题地图”。

用户访问一个陌生官网，脑子里通常带着四类问题：

1. 你们是做什么的？（对应首页/关于页）
2. 你们的产品或服务凭什么值得信任？（对应产品页、案例页、资质展示）
3. 我该怎么找你们，怎么购买，怎么售后？（对应联系页、FAQ）
4. 你们最近有什么动态、有没有权威背书？（对应新闻资讯、行业动态）

8个标准页面的信息架构，我在实际项目中习惯用这种方式划分：

首页要承担的职责不是“展示好看”，而是“在3秒内让用户知道你是干什么的，并愿意往下滑”。所以首页核心区必须包含一句话业务定位、一个核心产品入口、一组信任数据或合作品牌墙、一个明确的行为召唤按钮。很多新手做首页喜欢放一堆大图轮播，结果用户看了半天不知道这网站卖什么，这种首页就是失败的。

关于我们页则是信任感的深水区，公司的故事、团队的积累、项目的真实案例，都要在这里展示。有个常见误区是把“关于我们”写成自嗨式的公司简介，满屏企业文化口号，用户根本不关心。正确的思路是站在用户视角回答：“我凭什么相信你们能帮我解决问题？”

产品列表页要解决的是“逛起来不累”的问题，分类清晰、筛选直观、产品卡片信息一致。产品详情页要解决“看了想买或想咨询”的问题，别堆文字，多用场景图、参数表、同系列推荐。

新闻资讯和FAQ这两个模块，很多团队容易当“背景板”处理，随便填充几篇假文章就完事。但这两个页面恰恰是撑起官网内容深度的关键。新闻资讯传递的是“这家公司有持续的经营动态”，FAQ解决的是用户的潜在顾虑，把客户最常问的十几个问题摆在明面上，成交阻力瞬间就小很多。

联系我们页面看起来简单，设计讲究也不少。表单字段越少越好（姓名、手机、需求描述三件套够了），电话、邮箱、地址、地图一个都不能少，还要给出一个“加急”的沟通通道。事实上，很多用户最终不填表单，而是直接复制电话切到拨号界面，这个细节不能忽略。

2.2 视觉语言层：官网的“脸面”如何立住

信息架构解决的是“好用”，视觉语言解决的是“好看且可信”。官网的视觉设计不需要天马行空，但必须保持高度统一。

我给官网做视觉方案时，会先定三个东西：主色调、字体系统、卡片圆角与阴影规范。这三个定下来，所有页面的视觉基本盘就稳了一半。

主色调推荐不超过一主二次。主色用于按钮、链接、重点数据突出，次色用于标签、提示、辅助点缀，剩下全是中性色。官网的主色尽量选偏沉稳的色系（深蓝、墨绿、暖灰、暗红），因为官网代表的是企业信任，不是个人艺术家玩色彩实验。

字体系统分两块：中文用系统字体栈（思源黑体、微软雅黑、HarmonyOS Sans等），西文和数字用无衬线字体。正文字号统一14-16px，标题字号按层级递增（20/24/28/36），行高控制在1.6-1.8倍。千万别一个官网出现七八种字号，页面看起来瞬间就“野”了。

卡片圆角和阴影是官网精致感最重要的细节。圆角统一8-12px，大卡片16px，按钮全圆角。阴影用三层轻阴影叠加（低透明度黑+主色微光），避免生硬的默认边框。这些视觉规范看似琐碎，实则是官网从“普通”走向“专业”的分水岭。

2.3 技术架构层：Demo不是玩具，要为“转正”预留空间

官网Demo虽然叫“演示”，但它不能按照一次性玩具的标准做。就算这次只是给客户看一眼的Demo，客户看完觉得不错想正式上线，你也不希望全部推倒重写。所以技术选型和目录结构，一开始就要留出转正的余地。

我的习惯是：静态展示页面用纯HTML/CSS/JavaScript（原生或轻量框架），涉及数据动态渲染的部分预留接口层，等后端就绪后直接对接。

如果只是做纯静态的官网Demo，技术栈可以这样组合：

• 基础结构：HTML + Tailwind CSS（快速产出视觉统一的效果）
• 交互增强：原生JavaScript（导航吸顶、滚动动画、FAQ手风琴、表单校验）
• 动画方案：CSS过渡 + 少量IntersectionObserver驱动（比引一堆动画库更轻）
• 字体与图标：Google Fonts（或本地字体）+ SVG 图标

但如果官网里面涉及“文章列表动态加载、产品数据筛选、表单提交”这类需求，就得提前规划一下数据层。Demo阶段我一般这样处理：在项目里放一个mock/目录，里面用JS对象模拟真实接口数据，调用层统一封装成api.js，以后后端接口就绪了，只改api.js里的接口地址和字段映射，前端页面不动。这个习惯让我反复受益，客户半夜发消息说“后端好了，帮我把首页接一下”，我只需要改一个文件。

关于技术栈选择，我多说一句：官网Demo真没必要为了炫技引入重型框架。你用React/Vue写官网，确实能体现技术水平，但对这个项目来说运维成本高、加载速度慢、客户二次维护难。如果是个人接单，尽量选客户能接手、网上资料多的方案。说难听点，官网这种项目客户看重的是“能不能自己改文字换图片”，技术框架越轻越好。

3. 那一页特殊的“1”，决定了整个Demo的成色

8个标准页面是及格线，真正让Demo出彩的是“+1”这个特色页面。很多人做官网Demo，8个标准页中规中矩，但特色页随便搞一个跟首页差不多的模板糊弄，整体效果立刻掉价。这个“1”是整盘棋的彩头，必须花最多心思。

3.1 从业务场景倒推做什么样的“+1”

特色页的类型选择必须从业务场景倒推，不能为了特色而特色。我把官网常见特色页按用途分了四类：

第一类：在线体验类。比较适合SaaS、工具型产品。典型做法是做一个产品交互Demo区，用户可以在官网上直接输入数据、调节参数、看到实时效果反馈。比如一个数据报表工具的官网，特色页做一个“在线生成报表Demo”，用户选几个维度，前端立刻渲染出一张模拟图表。这种页面的好处是转化率极高，用户自己动手玩过产品，比看十页宣传文案都管用。

第二类：数据看板类。适合做B2B解决方案的企业。企业客户最关心的是“你们服务的客户到底得到了什么结果”，你可以做一个可视化数据大屏页面，展示模拟客户使用产品后的核心指标趋势（比如效率提升百分比、成本下降曲线、客户满意度分布）。这页视觉冲击力最强，适合在商务场合投屏展示。

第三类：交互营销类。适合活动推广场景。常见的有测一测性格/需求测试器、趣味计算器（报价计算器、节省成本计算器）、邀请函H5风格页面。例如一家做企业培训的公司，官网特色页就做“团队成熟度测评”，用户答完十几道题，得到一个分数和对应课程推荐。这页可以收集大量销售线索，是获客利器。

第四类：结构展示型。比较适合产品功能多、逻辑复杂的公司。做一个可交互的产品功能架构图，用户点击某一模块，旁边滑出该功能的详细说明和展示视频/图片。客户演示的时候不用一个个开文档，打开这页就能讲清楚产品全貌。

四类不限死，甚至可以把一和二结合：在线体验小工具+数据结果展示，一次搞定“玩过”和“看到结果”两个动作。

3.2 做一个“报价计算器”特色页的实操记录

我这里拿实际项目举例，把特色页实现思路完整说一遍。

某次接了一个企业服务官网的Demo需求，对方核心产品是“私域代运营服务”，8个标准页面做完后，我把特色页定为“私域成本估计算器”。用户在页面上输入员工数量、日均加粉目标、每月营销预算、行业类型四个参数，点击“开始估算”，页面动态展示一个结论卡片：预估每月投入成本、行业平均值对比、节省预算比例、推荐套餐方案。

实现上核心是两块：参数输入组件和估算逻辑算法。

参数输入组件不用造轮子，用原生的range滑块加数字输入框组合就行。滑块负责快速拖动，输入框负责精确控制，两者通过input事件双向同步。这个交互细节很加分，用户既喜欢拖动滑块的畅快感，也需要数字输入的精确感。

估算逻辑算法我用了二段式计算法。第一段算基础成本：员工数量 × 人均人力成本系数 + 营销预算 × 行业系数。第二段算对比值：用行业标准成本曲线做一次修正，算出用户的投入效率分。效率分在80分以上显示“成本控制优秀”，60-80显示“处于行业平均水平”，低于60显示“存在优化空间”，下面对应推荐不同层级的代运营套餐。

这个页面的技术实现不复杂，但有几个坑要提前提一下：

注意：范围滑块的值类型在获取时是字符串，参与计算前必须先parseFloat，我第一版忘了做，页面上怎么拖数值都不对，排查了半天才发现是字符串拼接问题。

另一个坑是边界值处理。用户可以拖到0，也可以输负数。我的方案是滑块min设1，输入框做Math.max(0, value)约束，同时在计算函数入口统一做一遍数值合法性兜底。官网是开放访问的，不能让用户传个0或负数进去，计算结果直接崩掉或面目全非。

视觉呈现方面，我没有写一堆繁琐的逻辑分支，而是准备了三个结论模板（优秀/平均/优化），根据结果动态切换卡片样式和关键词，再把计算结果用一个大号数字滚动动画展示。这个页面上线后客户非常喜欢，当场拍板把下一期运营委托项目也一起签了。

从这次经历总结，我的经验是：特色页与其做“炫酷动画”，不如做“有用交互”。动画特效用户看一眼就忘了，但“我调几个参数就能看到对我的价值”这页体验，用户会记很久。

3.3 特色页必须避开的三个低级错误

第一条：特色页不能脱离业务主流程。我做过的某项目里，客户强烈要求做一个“朋友圈九宫格海报生成器”，创意是挺好，生成的海报也确实好看，但访问者玩完之后不知道这公司卖什么、怎么联系。特色页再出彩，也必须带着官网的商业目标走——要么引导注册，要么引导留资，要么引导加微信，总之不能玩完就散场。

第二条：交互反馈必须即时且明显。用户点击、滑动、提交之后，页面一定要在1秒内给出反馈（按钮变状态、结果卡片滑入、进度条走完）。很多官网Demo交互页面，点击后半天没反应，用户会认为网站坏了。即时反馈不需要复杂技术，CSS的active状态、JS的节流防抖 + 状态切换就够了。

第三条：别把所有特效堆在一页上。部分开发者觉得特色页就要“炸”，粒子背景、3D翻转、视差滚动、音效全上了，结果加载慢、卡顿、看着累。特色页做“一处亮点”就够了：要么交互方式有趣，要么数据呈现美观，要么页面讲述有节奏。贪多必失。

4. 实操过程中用到的高频模块与细节技巧

进入具体开发阶段之后，8个标准页面的很多模块都是重复的，处理效率直接影响交付进度。我把官网Demo里复用率最高的几个模块和细节优化记录下来，这部分才是日常开发中真正省时间的部分。

4.1 头部导航：吸顶、状态切换、移动端适配

全站头部导航是用户接触最多的组件，也是最容易做糙的地方。

推荐做法是首屏透明导航、向下滚动后吸顶并加背景色，这个交互虽然老套但非常稳定。实现方案用CSS的position: sticky加backdrop-filter就够了，不用监听滚动事件，省掉大量性能消耗。首屏要展示大Banner的页面，导航文字用白色，滚动后背景变白、文字变深色。需要注意切换过程的过渡时长设为0.3秒，太慢显得黏糊，太快没有感知。

移动端导航是官网开发的重灾区。Hamburger菜单展开后必须有遮罩层（防止误触穿透），菜单项点击后自动收起，收起动画用height或transform实现，不能用display瞬切。展开状态下页面滚动要锁定（overflow: hidden加到body），很多站点忘了这步，菜单展开时背景还能上下滑，观感很差。

导航还有一个容易忽略的细节：当前页面高亮。导航项需要根据当前页面路径高亮对应菜单，这个用简单的比较当前路径和菜单href前缀就能实现，但很多Demo没有做，用户浏览时不知道自己在网站哪个位置，导航就失去了向导价值。

4.2 图片与多媒体处理：官网颜值的地基

官网Demo图文占比极大，图片处理不当会严重影响加载速度和视觉质量。我先说一个容易被忽视的原理：图片清晰度和体积成正比，官网追求的是“看起来清晰”，而不是“真实100%原图”。一张3000px宽度的营收玻璃大厦照片，直接丢进首页当背景，体积可能是3-5MB，浏览器要卡两秒才出来，体验极差。

我的处理习惯是这样：Banner背景图宽1920px，压缩质量80%，体积控制在200KB以内；内容区配图宽1200px以内，质量75%，格式优先用WebP。实际操作时我用图像压缩工具批量处理，一张张操作太浪费时间。

懒加载也是必须做的。列表页、新闻页的图片用原生loading="lazy"属性即可，配合decoding="async"让浏览器异步解码图片，首屏加载速度肉眼可见地提升。还有个容易被漏掉的点：列表页每张图片都要给固定宽高比（比如4:3或16:9），防止图片加载完成后页面内容跳动。这个体验细节是专业站和业余站的分水岭。

视频模块的用法需要注意：官网Demo不建议背景自动播放带声音的宣传视频，强制播放声音会让用户立刻关掉页面。如果一定要放视频，用静音自动播放循环的视频做氛围背景，声音由用户主动点击开启。

4.3 表单系统：联系页和预约模块的隐藏难点

表单是官网中“看着简单写着坑”的模块。一个联系表单通常包含姓名、手机号、邮箱、需求描述，再有个提交按钮就完事，但实际开发中表单才是开发时间占比最高的模块之一。

第一层坑是前端校验。手机号用正则校验时，必须考虑常见号段更新，我用的是宽松匹配（11位且以1开头），而不是硬编码一堆号段。邮箱校验用基础格式正则即可，别太严，不小心把abc+test@domain.cn这类合法邮箱拦了。

第二层坑是交互反馈。用户点击提交按钮后，按钮要进入“提交中”状态（禁用 + 转圈），防止用户手滑连点；成功后要出现成功提示（弹层或页面内提示）；失败时要把错误信息具体告诉用户（“网络异常，请重试”比“系统错误”让人安心一百倍）。所有反馈都要在2秒内出现，拖久了用户以为没提交上又点了一遍，把服务器的重复数据都给造出来了。

第三层坑是防刷与限制。完完整整的防刷方案（比如验证码、频率限制、IP限制）需要后端支持，但Demo阶段至少要做一次前端节流：用户提交成功后，3分钟内禁用再次提交。这个实现门坎为零，但能挡住一大批手滑和初级刷子。

我见过太多官网Demo把表单做完后自己都不测一遍，结果客户收到询盘全是空数据。开发完一定要把自己当用户，干净利落地填一遍表单，再故意填错几次，看错误提示是否友好。

4.4 内部锚点与内容区块组织

官网页面大多很长，用户滑到第三屏就迷路了。内页的“章节目录”、首页的“秒懂分层”，本质上都是在帮用户建立心理地图。

实操上，长页面要用“模块编号 + 标题锚点 + 平滑滚动”来组织。每个模块分配一个带业务语义的id（比如#solution、#cases、#contact），导航或按钮跳转时用scrollIntoView({ behavior: 'smooth' })，或者CSS的scroll-behavior: smooth配合a[href="#id"]就能实现。需要注意避开吸顶导航遮住标题的问题：给锚点目标加scroll-margin-top: 80px，就能完美避让。

关于内容区块的疏密度，我坚持一个原则：宁可内容短，不要满屏字。每个内容区块拥有“标题 + 副标题 + 简述 + 配图/图标”四件套就足够了，信息再多就拆成卡片或列表。用户浏览官网是扫读不是精读，密密麻麻的文字段落在官网场景里几乎不会被读完。

5. 移动端适配与跨端体验

官网Demo如果只做桌面端，会被打回重做。现在企业采购官网明确要求移动端适配，移动端的访问量早就碾压桌面端。这里说的适配不是简单“缩小了能看”，而是移动端的操作习惯、信息层级、触控大小都要重新梳理。

5.1 弹性布局与断点设计

在弹性布局和断点设置上，我推荐采用三个断点方案而非一锅端：手机端断点（≤768px）、平板端断点（769-1024px）、桌面端断点（≥1025px）。

手机端的核心原则是单列布局、大触控区、关键信息前置。导航压缩成汉堡菜单，表格在移动端改成卡片堆叠，按钮高度保持44px以上（这是触控标准高度）。平板端的处理策略介于两者之间，可以保持双列布局，但要控制文字宽度不要拉得太长，图集自适应。

断点变化量不要太多。很多新手做适配时，把字号、间距、圆角、布局全部换一套，结果手机端看起来像另一个网站。正确做法是：布局结构换掉（比如两列变一列），字号变化控制在20%以内，色彩体系、圆角、阴影保持不变，这样移动端只是“重新排了一下队”，视觉品牌还是一家人。

5.2 触控交互要重新设计

触控交互不是“鼠标点击的缩小版”，它有自己独特的行为逻辑。官网Demo开发中常见的移动端触控问题有三个：

第一个是点击热区过小。桌面端文字链接10px字都能点，但移动端手指头的精度远低于鼠标，至少要保证44px的点击区域。小图标链接、标签筛选按钮，都要通过padding撑大点击区域，看起来视觉很小但触控有效。

第二个是下拉选择框体验差。官网表单里常见的城市下拉选择框，原生<select>在移动端弹出的是系统滚动选择器，通常还能接受。但如果你用自研的下拉列表组件，就要特别注意滚动穿透问题：下拉列表弹出时，背景页面的滚动必须锁死，否则会出现两层内容一起滚的世纪难题。

第三个是悬停态失效。桌面端的悬停样式（如:hover）在触屏上不起作用，但代码不会崩，只是看起来像“没反应”。做桌面端时我会保证所有悬停样式都有对应的点击态、焦点态样式，这样在移动端不显得烂尾。同时，像“点击卡片跳转详情”这个动作在移动端要确保点击整张卡片任意位置都能触发，而不是只能点那个小小的“了解更多”链接。

5.3 跨端量度与性能表现

性能问题在移动端被放大得尤其明显。同一个网站在桌面端有缓存、网速快、屏幕大，慢一点没感觉；在手机上稍慢就会直接劝退。我优化官网性能的步骤是：

从图片体积和数量入手（压缩 + 懒加载 + WebP），这个处理的收益最大。接着优化字体加载，字体文件用font-display: swap，优先显示系统字体，等自定义字体加载完再替换，避免文字白屏等待。再复用CSS代替JS做动画，至少保证页面首屏交互的JavaScript尽量精简，避免一个几百KB的脚本阻塞首屏渲染，拖慢页面打开。

有一个很实用的移动端性能小细节：把滚动事件里的复杂逻辑全部改成requestAnimationFrame节流，或者干脆不做滚动监听。部分开发者写吸顶导航用 scroll 监听大计算量的函数，手机上滑动时页面像PPT一样一顿一顿的，就是因为主线程被滚轮计算撑爆了。我在实际项目的折中方案是：能用position: sticky解决的绝对不用滚动监听，检测方案用 CSS 原生方案优先。

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

官网Demo开发周期短，交付节奏紧，出问题最多的往往是那些“看起来不是问题”的地方。我整理了这么多年做官网掉坑的真实记录，挑典型的几类说一下，碰到类似情况可以少花半天时间排查。

6.1 导航吸顶出现跳动或错位

页面滚动后导航吸顶，内容突然往上跳一下，看起来整页像“抖”了一下。核心原因是position: static切换到position: sticky/fixed后，导航脱离了文档流，原本占据的高度突然腾空，页面内容冲到顶部。

解决方案很简单：给导航的父容器设置固定高度（比如64px），或者给导航初始就设置为position: fixed并给它下方留一个相同的占位元素。实操时我习惯给header外挂一个高度等于导航高度的空div，这样无论是否吸顶，下方内容都不会跳动。

另一个吸顶的隐蔽问题是横向滚动时错位。固定导航如果使用了百分比宽度或100vw宽度，在出现纵向滚动条的页面上会多出一截横向滚动，因为100vw包含了滚动条宽度。解决办法是用position: fixed下配合left:0; right:0而不是width:100vw。

6.2 表单无法提交或提交后无响应

表单提交无反应这种问题，排查顺序比乱猜重要。第一步先看浏览器控制台有没有JS报错（红字），八成是某个变量未定义或接口地址拼错。第二步看网络面板，表单请求有没有发出去，返回状态码是多少。前端正常、接口返回500或者404，那是后端或路径问题。第三步登录服务器看日志，确认请求是否真正到达。

个人最常踩的坑是：前端校验通过了，但表单数据中有字段值为undefined，传给后端后业务逻辑异常，直接返回500。排查时先给提交数据加一个console.log(JSON.stringify(data)),一眼就能看出来字段名是否拼错、有没有undefined。

另外补充一个反直觉的知识点：同一个页面不要放两个ID相同的表单字段。页面上引用了第三方统计代码或客服组件时，可能页面里会注入隐藏的同名字段，导致提交数据混乱。所以我每个表单字段的name属性会起得很具体（比如contact_name_11），避免和全局库冲突。

6.3 图片加载错位与懒加载失效

图片懒加载失效的典型症状是：首屏之上的图片懒加载不出来，页面一片空白。原因在于部分懒加载插件把loading="lazy"与滚动监听混着用，初始时不加载任何图片，但首屏图片并不需要懒加载，必须立即加载。

解决思路：首屏图片不用懒加载，内容区以下的图片再用懒加载。判断方法简单粗暴：凡是打开页面就能看到的图片（Hero区域、导航Logo），全部移除loading="lazy"。

图片加载后内容错位，本质是宽高比没锁死。解决办法是在CSS里给图片容器预设aspect-ratio属性（如aspect-ratio: 4/3），图片加载完成后直接填充，不再挤动周围布局。注意老浏览器不支持aspect-ratio，可以退而求其次用padding-top百分比写法兜底。

6.4 跨浏览器样式不一致

官网交付之后，团队内部测试没发现问题，结果客户在另一台电脑的旧浏览器打开，布局整个崩掉。最常见的来源是CSS新特性兼容性：backdrop-filter（毛玻璃）在部分浏览器不支持、aspect-ratio在旧版本不支持、gap在Flexbox早期版本不支持。

我的策略是：先进特性给予优雅降级，而不是全面放弃。使用backdrop-filter时给导航背景加一个半透明的纯色兜底，这样不支持毛玻璃效果的浏览器也只是少一点通透感，不影响功能。使用新特性的同时备注针对旧内核浏览器的降级方案，不要为了实验效应把可用性抛弃了。

另外我用到的“自动化兜底”是配套自动化工具处理兼容问题，自动补全大部分前缀和降级，但仍建议手工检查一下backdrop-filter、position: sticky、aspect-ratio这类高影响属性。

6.5 “404”也要做得像个官网

官网Demo基本都会漏掉404页面，我每次都会主动补上。这个页面不需要复杂，但必须延续官网的品牌视觉，加上一句解释文案、一个返回首页的按钮、一个搜索框就更好了。

404页面反而是一个免费制造好感的窗口：页面走心、响应快、给用户“返回正轨”的路径。访客看到404后的第一感受是这网站维护得到不到位，一个粗糙的404页面会让人联想到背后公司也草草了事。

7. 从Demo到正式交付：最后一步千万别省

有些人的官网Demo是在本地开发完截图给客户看，然后彻底结束。但如果你想在这个项目上留下好口碑，甚至拿到后续业务，交付阶段的细节能体现真正的职业素养。

7.1 本地预览与部署

Demo阶段至少要在本地起一个服务，而不只是双击HTML文件打开。双击打开时部分浏览器的API行为异常（fetch失败、模块加载CORS报错）。我常用简单的方式起本地服务：项目目录下执行一行命令起一个静态服务，浏览器访问localhost:端口，模拟线上路径结构，避免各种本地访问特有的奇怪问题。

部署方面，如果只是给客户演示，可以用任意支持放置静态站点的托管平台，上传文件夹就能访问。但要注意一点：Demo不要用自己电脑的IP加端口让客户访问。一是IP地址难记，二是电脑关了访问直接挂掉，给客户印象极差。放到线上托管后，给客户一个规整的链接，专业感立刻拉满。

7.2 交付目录与文档

交付时不要把一堆源文件压缩包丢过去就完事。我通常会整理正式交付目录，按“站点源文件 / 设计资源 / 说明文档”分类。文档里写清楚：怎么本地打开、文件目录结构、每个页面对应的文件名、图片字体资源在哪里、表单提交对接方式、后续如何修改文字/图片/替换联系方式。

写这一步看起来多余，但对客户来说价值巨大。客户接收后如果不是立刻上线而是过了两个月再接手，一份清晰文档能省下无数沟通成本。而且把联系方式、替换入口写清楚，客户后续自己想改就不会找你，遇到真正需要开发的，再回来找你付费，这是用文档做的长期生意。

给客户演示时还有一个小细节：不要直接展示本地localhost，也不要展示一堆无意义目录。直接把线上网址打开，花两分钟讲一遍首页逻辑、重点页面、特色页的玩法，然后留时间让客户自己玩。客户玩明白特色页后自己提交一次表单，收到“提交成功”的反馈，这个体验比自己讲五十页PPT都有效。

7.3 复盘：做完一个官网Demo，留下什么

每个官网Demo，哪怕再小，做完后都值得花半小时复盘一次。复盘不是自我感动，而是把这一次项目中踩到的坑和验证过的技巧沉淀下来。我的复盘清单很朴素：这次项目里效率最快的模块是什么；哪个环节消耗时间超出了预期，下次该怎么避免；有没有可以转成通用组件的代码。

把页面里重复用到的导航、轮播、卡片、表单校验、图片懒加载这些代码抽成模板，放到自己的代码仓库里，下次做官网直接复制改数据就行，这一下就能节省几小时。做官网Demo是个重复度极高的项目类型，真正拉开差距的不是创意，而是复用能力——谁能把常见的需求做成了模板，谁就能在三天内交付一个看起来像两周工期的官网。

我在这个项目里最后留存下来的，就是一套官网组件模板和一个自己梳理的“需求澄清问题清单”。这套东西在后来的三个官网项目里直接复用，每次开头省下的沟通和排版时间，够我多打磨几次特色页交互了。

如果你正在准备做官网Demo，从上面的思路出发：先把“8+1”问清楚，再立好信息架构的骨架，把标准页面做到无短板，最后把精力集中在那个“1”上面——特色页不是锦上添花，而是整个Demo让人记住的核心。

我在实际交付中最大的体会是：客户对官网的最终评价，很少来自某个页面做得多么细腻，而是来自“整个官网像是一个配套完整的系统”带来的综合感受。用这套思路实现官网Demo，即使时间紧张，也能稳稳做到让大多数客户满意。