企业官网建设流程全解析

2. 页面实现的核心细节

一说到官网demo，很多人第一反应是：静态页面而已，套个模板快得很。真做起来才发现，8个业务页面加1个联动演示场景，能暴露出的问题比想象中多得多。我这次做的就是一个偏B端产品的官网demo（8+1），用来给销售和客户现场演示，也兼着给团队评审用。如果你正在做类似的预览站点、投标演示版、或者是市场团队要的尝鲜版，这篇文章里的方法可以直接照着抄。

“8+1”里那8个页面，对应的是官网导航上的常规内容：首页、产品中心、解决方案、客户案例、关于我们、新闻动态、加入我们、联系我们。剩下那个“+1”，不是常规的404或搜索页，而是一条隐藏在路由里的演示故事线页面。它把所有业务页面串成一条连贯的演示路径，现场讲的时候不用手动来回切换，客户也不会被零碎操作打断思路。

这个项目从定需求到落地一共用了两周，技术栈用的是Vite + React + TypeScript + Tailwind CSS。下面我把整个拆解过程、每个页面的实现思路、还有踩过的坑都写出来。文章里的代码和做法都是实际跑过的，不是纸上谈兵。

1. 需求拆解：8+1页面不是拍脑袋想出来的

1.1 先把页面目的写清楚，再动手写代码

开始写代码之前，我先把每个页面在纸上画了一遍信息架构。这一步看着简单，恰恰是demo能不能“像官网”的关键。很多demo做出来假，就是因为首页堆了一大堆营销话术，产品页却连核心功能入口都没有，客户看着看着就不知道你在讲什么了。

我当时的页面划分和演示目标是这样的：

这样一列就发现，所谓“8+1”不过是最小可用官网集合。如果你正在做的是一个更成熟的产品，可能还会拆出“定价页”“文档中心”“开发者社区”等等。但作为demo，9个页面已经足够覆盖一次产品演示的主线了。

1.2 选型：为什么我不先用全家桶

做demo我见过最亏钱的做法，是还没想清楚就拉一个Next.js全栈项目，再配上一个重型后台框架，光初始化就折腾半天。对这种预览性质的官网，我的原则是：能静态就静态，能轻就轻。

这次选的是Vite 5 + React 18 + TypeScript 5。理由很简单：Vite冷启动快，热更新顺手，构建出来的产物是纯静态文件，扔到任意一台能装Nginx的机器上就能跑。React Router v6做多页面路由，Tailwind CSS负责样式。没有引入状态管理库，直接用一个React Context + URL参数处理跨页面的演示状态，demo规模下完全够用。

注意：如果这个官网之后要长期迭代、做SEO，那需要考虑迁移到Next.js。但那改造成本其实不低，所以我建议一开始就明确：这是demo/预览版，正式版另起炉灶。别让demo背负多余的复杂度。

1.3 那个“+1”到底是什么

“+1”是一个独立于导航的演示导览页，路由我设为/story。它不显示在顶栏和页脚里，只能通过特殊入口或直接输入URL访问。页面上放着“产品演示”“解决方案演示”“案例数据演示”三张卡，每张卡对应一段演示脚本。

点击其中一张卡，页面会携带一个参数跳到目标页，比如/products?story=core-features。目标页在加载时读取参数，自动高亮预设的功能模块，并在页面角落显示一个“返回导览”的悬浮按钮。客户在现场看的时候，整个演示像看PPT翻页一样顺畅，不会出现“等一下我找一下那个页面”的尴尬。

这个设计我当时完全是即兴加的，结果意外成了整个项目里最有存在感的功能。它解决的其实不是技术问题，而是一个很现实的问题：demo人员在现场会紧张，一紧张就手忙脚乱，与其依赖临时发挥，不如让页面替你把节奏安排好。

2. 核心细节解析：每个页面我到底做了什么

2.1 顶部导航和路由过渡：统一是安全感的来源

导航我没有单独用前端框架组件库，而是自己写的一个固定顶栏。B端官网的导航通常层级不深，用下拉菜单反而制造混乱，所以我把导航设计成纯平铺，产品中心和解决方案动效上有点小交互，但内容不藏导航层级。

这里有个我每次都要强调的细节：导航的高亮状态一定不能高亮错。比如产品详情页/products/detail/1，导航“产品中心”必须保持高亮。这个逻辑用React Router的useLocation和路由规则匹配就能做，不要用字符串startsWith硬匹配，否则以后加二级路径容易踩坑。

路由过渡我用了最轻量的方式：页面切换时加一个透明度 + 位移的纯CSS动画，利用View Transition API或简单的key变化重置动画。很多团队会引入framer-motion做全屏页面过渡，但在这种需要快速加载的演示站点里，动画库的包体负担有点不划算。现场演示时，客户不需要那种夸张的转场，干净利落反而是专业感的来源。

2.2 首页：把首屏当成产品发布现场

首页是整个demo的门面。我的首页结构是：首屏大标题（写明行业+产品一句话价值）-> 三条核心产品线卡片 -> 数字化指标数据墙 -> 客户Logo墙 -> FAQ，最后一屏是联系我们。

首屏我特意压缩成了一个高度正好占满一屏的半屏Banner加半屏产品入口预览。客户第一次打开，不用滚屏就能看到“你是谁、你解决什么问题、你有哪些产品”。这三件事在前3秒讲不清楚，后面再精致都是白搭。

产品入口卡片我用了大图标 + 一句话描述 + “查看详情”链接。排布上没有做成对称三列，而是中间略大、两边略小，制造层级感。这个方案最初拿UI稿给团队看的时候，有人嫌不对称、太冒险，但演示现场用户的视线会在三个产品之间自然移动，反而达到了引导探索的目的。数据指标墙用的是客户现场就能看懂的大数字，不是那些“平台智能率”之类的自嗨词。

2.3 产品中心：用mock数据统一管理，替换成本降到底

产品中心这个页面，demo阶段没有真实API，所以我用了本地mock数据。但这里的mock不是随便硬编码在组件里，而是单独维护了一个mocks/product.json，并且定义了完整的TypeScript类型：

export interface ProductCategory { id: string; name: string; description: string; icon: string; features: ProductFeature[]; } export interface ProductFeature { id: string; title: string; subtitle: string; desc: string; icon: string; screenshots?: string[]; }

页面里所有筛选、详情、锚点跳转都基于这份数据。产品列表左侧是分类筛选，右侧是卡片流。点击卡片后在当前页面打开一个侧滑详情层，里面包含功能特性、适用场景、几张示意截图。侧滑层的好处是切换产品不用跳转页面，演示时连续看两三个产品不会因为浏览器前进后退而显得乱。

我当时特意不把产品详情做成独立路由页面，而是做成抽屉，背后有个很实际的原因：客户在demo现场经常是“对比着看”，选完A产品马上想看B产品。如果做独立页面，来回切换容易出现白屏、滚动位置丢失这些小问题。侧滑层天然规避了这个麻烦。

这个方案有个代价：产品详情无法通过链接直接分享。所以我在每个侧滑层右上角放了一个“复制详情链接”按钮，生成类似/products?detail=core-system的URL。其他设备打开时，路由读取参数自动打开对应详情层。这样既保留了单页切换的流畅，又不丢失链接直达能力。

2.4 解决方案页：按角色讲场景，按行业配故事

解决方案页最忌讳的是单纯把产品功能罗列一遍。B端客户关心的不是你有多少功能，而是你的方案能不能解决他遇到的痛点。所以我把解决方案拆成两层：一层按角色（比如决策者、业务负责人、一线执行），一层按行业（比如制造、零售、金融）。

角色方案用的是卡片式布局，每张卡片配一个“该角色每天会遇到的三个问题”，然后才是方案概要。行业方案则用更轻的横向tab切换，进入某个行业后展示一句行业洞察 + 典型应用场景 + 对应客户案例链接。这样观众可以从两个维度切入，demo人员也可以根据现场观众身份快速选择合适的演示路径。

这里的实现细节：横向tab切换时，我保留了每个tab独立的滚动位置和筛选项状态，切换回来不会丢内容。原理是把各tab的内容区分别做成独立的列表组件，不共用全局筛选状态。这个细节听起来小，但现场演示时非常加分。

2.5 案例页、关于页、新闻页、招聘页、联系页：简单页面反而考验耐心

这五个页面在整个demo里功能占比不大，但恰恰最容易露怯。我见过很多demo项目，首页和产品页做得花团锦簇，一到关于我们页就崩了，排版错位、图片加载失败、联系方式甚至还是“110@example.com”这种占位内容。页面越简单越不能糊弄。

案例页我做得相对重一些，列表带行业筛选和关键词搜索，数据同样来自mocks/cases.json。案例详情用的也是侧滑层，里面包含客户背景、痛点、方案、效果数据和客户证言。数据地方我刻意把“效果提升XX%”放在卡片表面的右上角，观众扫一眼就能看到收益——B端案例的冲击力就靠这一眼。

关于我们页走的是简洁路线：公司简介 + 一组发展历程时间轴 + 核心团队卡片。这里团队卡片用了占位头像，我是用随机头像服务生成的，但要提醒大家：demo可以，上线前必须换成自己的素材。新闻动态页就是文章列表加筛选标签，文章内容我用几段真实感的样例文本充数，标题写得专业一点，不然客户一眼就看出是虚拟内容。加入我们页没有做完整的招聘系统，只做了职位列表+筛选+申请按钮，点击后就跳出“提交成功”的toast提示，因为demo阶段没必要接真实表单。联系页是我唯一下功夫做交互的页面：表单做了前置校验、成功态动画和演示预约入口，电话、邮箱、地址全部放真实可用的占位数据。

关于页面这批内容的统一性，我组了一个PageHeader公共组件，统一控制所有内页的标题区、面包屑和简介文案。不然九个页面各自写一套头部，视觉上会很散。

3. 实操过程：多页面协同、交互细节和视觉体系是怎么落的

3.1 页面间数据联动：一个Context让整个demo活起来

官网demo的页面之间本应该是弱耦合的，但为了实现“+1演示故事线”的效果，我需要跨页面共享一部分状态。我没有引入Redux，而是写了一个小组件DemoProvider，挂在路由根节点上：

const DemoContext = createContext<DemoContextType | null>(null); export function DemoProvider({ children }: { children: React.ReactNode }) { const [storyMode, setStoryMode] = useState(false); const [activeGuide, setActiveGuide] = useState<string | null>(null); const startStory = (step: string) => { setStoryMode(true); setActiveGuide(step); window.sessionStorage.setItem('story_step', step); }; const endStory = () => { setStoryMode(false); setActiveGuide(null); window.sessionStorage.removeItem('story_step'); }; return ( <DemoContext.Provider value={{ storyMode, activeGuide, startStory, endStory }}> {children} </DemoContext.Provider> ); }

为什么用sessionStorage而不是直接只在内存里存？因为现场演示随时可能刷新浏览器，一旦刷新，内存状态就丢了。存到sessionStorage后，刷新页面仍然保留当前演示步骤，可以无缝继续讲下去。这个细节我调试了几次才发现需要加，不然演示到一半手滑按了个F5，整个导览状态就重置了，非常尴尬。

具体联动逻辑是：/story导览页点击某一步，写入sessionStorage；目标页面加载时读取并高亮对应区域，同时页面右上角常驻“回导览”悬浮按钮。如果用户在演示路径上点了导航去别的页面，悬浮按钮不会自动消失，得点一下结束导览才会清除状态，保证“逃逸”后也能拉回来。

3.2 动效：入场动画、数字滚动，哪一些值得做

动效这块，我给自己定了个规矩：能用CSS解决的不碰JS动画库。整个项目里我只写了一个通用Reveal组件，用来做元素进入视口时的渐显动画：

import { useEffect, useRef, useState } from 'react'; export function Reveal({ children, delay = 0 }: { children: React.ReactNode; delay?: number }) { const ref = useRef<HTMLDivElement>(null); const [visible, setVisible] = useState(false); useEffect(() => { const el = ref.current; if (!el) return; const observer = new IntersectionObserver( ([entry]) => { if (entry.isIntersecting) { setVisible(true); observer.disconnect(); } }, { threshold: 0.15 } ); observer.observe(el); return () => observer.disconnect(); }, []); return ( <div ref={ref} style={{ opacity: visible ? 1 : 0, transform: visible ? 'translateY(0)' : 'translateY(24px)', transition: `opacity 0.6s ease ${delay}ms, transform 0.6s ease ${delay}ms`, }} > {children} </div> ); }

这里有个经验是：Threshold不要设成1，那个要求元素完全进入视口才触发，首屏下方一点点的内容会迟迟不出现。0.15左右最舒服。此外还有一个细节：触发一次后立即断开观察器，避免元素来回进出视口时反复播动画，显得很廉价。

首页数据指标墙的数字滚动动效，我写了个useCountUp的Hook，在组件进入视口后用requestAnimationFrame驱动数字变化，600毫秒内从0增到目标值。为什么不直接做CSS动画？因为CSS对数字内容的插值支持有限，@property这招在老旧浏览器上不兼容。这个Hook大约40行代码，常驻在项目里以后做B端营销页还能复用。

3.3 视觉语言：颜色、圆角、字体、间距统一成变量

表格在这个项目里最大的作用，不是数据好看，而是让九个人看得像同一个系统的。

我在tailwind.config里扩展了主题变量，把所有核心token集中管理：

theme: { extend: { colors: { brand: { 50: '#f0f9ff', 100: '#e0f2fe', 500: '#0ea5e9', 600: '#0284c7', 700: '#0369a1', }, }, borderRadius: { DEFAULT: '10px', lg: '16px', xl: '24px', }, boxShadow: { card: '0 1px 3px rgba(0,0,0,0.06), 0 8px 24px rgba(0,0,0,0.06)', }, }, },

全套页面只用一个主色体系，辅助色控制在三种以内。字体方面我最终选择了最稳妥的方案：中文字体不引入任何自定义WebFont，直接用系统字体栈。原因是中文在线字库体积动辄几百KB甚至几MB，对演示环境不友好，而且客户现场网速差时字体加载会严重摧毁首屏体验。用系统字体栈虽然视觉上没那么“品牌感”，但换来的是稳定和快，这对demo站点是更重要的事。

卡片阴影我只定义一个token，全站所有卡片都用同一个阴影。按钮高度、圆角、字号也都有变量约束。别小看这些变量，它们能让没有专门UI介入的demo阶段保持视觉一致性。实际开发中我见过太多demo项目：第一页用大圆角，第三页用小圆角，首页按钮有阴影，案例页按钮没有。这些不一致的观感，客户现场一对比就会被放大。

3.4 图片资源治理：体积、格式、占位策略

demo内容里的图片我全部做了一轮压缩处理。原始设计稿导出的截图经常是2~3MB的PNG，直接进项目会把页面拖垮。我在项目根目录加了一个简单的脚本，用sharp把所有图片统一转成WebP，并限制最长边不超过1600px。压缩完之后，单张图片基本都控制在80~150KB之间。这里我建议不要偷懒用原图哪怕只是demo，现场演示的电脑配置千奇百怪，一张大图卡顿会让整场演示变得很难看。

占位图统一用一个本地SVG组件，生成带品牌色的抽象色块，避免第三方占位图服务在客户内网环境下加载失败。我踩过一次这样的坑：第一次演示时用了外部图床，现场客户公司网络策略比较严格，图片全挂了，整个页面就像被撕了一大块。从那次以后，demo项目所有资源一律本地化，不依赖任何外网CDN。

4. 性能与部署：让demo在任何一台演示机上都能流畅打开

4.1 目标：不是Lighthouse 100，而是“秒开”

很多人做demo喜欢盯着Lighthouse跑分，我反而觉得，关键指标只有一个：在一台没有多余优化的普通Windows笔记本上，用Chrome开无痕窗口访问，能不能在2秒内看到首屏主体内容。Lighthouse分数高但真实环境一塌糊涂的站点你我都见过。

我在构建配置上做了三件事：

第一，按路由拆包。React Router v6天然支持懒加载，每个页面对应独立的JS chunk：

const HomePage = lazy(() => import('@/pages/HomePage')); const ProductsPage = lazy(() => import('@/pages/ProductsPage')); const SolutionsPage = lazy(() => import('@/pages/SolutionsPage'));

注意：懒加载的路由组件，切换时会有短暂的白屏。我额外做了一个全局Suspense，fallback是一个轻量的页面骨架。骨架屏不用复杂，灰色区块 + 一点淡入动画就够了，关键是让用户感觉页面在“加载内容”而不是“卡住了”。

第二，手工拆分第三方依赖。Vite默认的chunk策略会把所有node_modules里的代码打到独立块里，但不一定合理。我的vite.config.ts里手动把React相关、开源的图表库、工具库分别拆了一份。这样首屏只用加载React核心，图表库进入对应页面时才拉取。

第三，关键字体和首屏图片预加载。图片我用了loading="lazy"让非首屏图延迟加载，但首屏Banner图反而要主动预加载，不能等浏览器决定。这个“正向懒加载+关键资源预加载”的差异，是很多前端容易搞反的地方。

我当时实测的一个调优前后对比：基础版打包产物体积约1.1MB（未gzip），首屏加载在演示机上要3秒多。经过上述拆分、压缩、图片处理之后，首屏JS+gzip约180KB，本地环境几乎做到秒开。这个收益在项目早期可能不显眼，但在现场演示时能明显感受到胆气壮了不少。

4.2 骨架屏和首屏体验

骨架屏这件事值得展开讲。很多React SPA在首屏都有一个通病：第一个画面是白色，然后突然闪现完整内容，用户会觉得“网页加载了，但刚才那个白色是什么情况”。

我写了一个PageSkeleton组件，根据每个页面的布局生成对应的骨架结构。首页的骨架是顶部导航栏+首屏banner+三列卡片的大色块占位；产品页则是左侧筛选器+右侧卡片网格的骨架。组件不大，每个页面几十行代码，但它对演示体验的提升非常明显——客户不会在加载的几秒里盯着白屏发呆，而是在看一个“正在成形”的页面。

懒加载还会带来一个坑：同一时刻多个chunk并发请求，容易触发浏览器的同域名并发限制。所以我把所有公共依赖全部打进了initial chunk，只有页面自身的逻辑才是懒加载。这样切页时只有一个新chunk要拉取，延迟会低很多。

4.3 部署与发布：静态文件扔到任何机器都能跑

整个项目构建完成后，产物是/dist目录下的静态文件。我用了两种部署方式：一个是在团队内网用Nginx起一个静态站点，另一个是直接扔到一台便宜的云主机上用serve跑。两种方式都只需要一行命令，不需要配数据库、不需要环境变量。

这里有一个经验：Nginx配置一定要记得解决路由history模式导致的404。React Router默认是BrowserRouter，刷新/solutions/manufacturing这个路径时，如果Nginx没有做try_files回退，会报404。我在部署配置里写了：

location / { try_files $uri $uri/ /index.html; }

很多新手在这儿翻车，看起来是“页面能打开”但一刷新就挂。demo现场最怕这种意外，所以当时我在检查清单里专门加了一条：所有二级路径刷新必须在部署前验证。

5. 常见问题与排查技巧：demo路上那些坑，一次讲完

5.1 字体闪烁、样式错乱、图片抖动，这类首屏问题怎么定位

这套demo做完，前后遇到的几个常见问题我整理成了一个速查表：

这里面最值得说的就是第三行那个问题：当时我把整个页面（包括导航框架和路由出口）都放在Suspense里，结果切页时整个页面都变成骨架屏，导航也跟着闪。后来把布局拆出来：

<DemoProvider> <SiteLayout> {/* 导航和页脚固定在这里 */} <Suspense fallback={<PageSkeleton />}> <Routes>...</Routes> </Suspense> </SiteLayout> </DemoProvider>

改动只有几行，但演示时的“页面整体闪动感”立刻消失了，只有中间内容区做加载替换，体感上专业了许多。

5.2 现场演示的三大风险：网络、环境、演示人员手滑

网络上踩过的坑前面提到过，就是不能依赖任何外部资源。具体来说，我把图片、图标、字体全部本地化，接口全部打桩，整个demo站点在完全断网的情况下也能跑。这不是吹毛求疵，而是现场演示高频发生的场景：客户的会议室要么WiFi受限，要么网速奇差。你要确保打开一级页面时不需要等待任何外部请求结束。

环境上的坑更隐蔽。有些客户的公司电脑会弹“360安全卫士”拦截小弹窗，或者默认浏览器是某个老旧内核。我当时准备了非常具体的演示清单：提前用一个U盘把整个/dist文件夹装进去，如果现场没有网络，就启动一个本地静态服务（用Python的python -m http.server 8000都可以），然后开一个无痕窗口访问。无痕窗口的好处是避免浏览器插件（比如广告拦截、翻译插件）干扰页面样式和渲染。

演示人员手滑这个问题，我用了前面讲的路由导览来兜底。导览页上每张卡都有预设的URL参数，点击后自动进入对应演示步骤。就算某个步骤讲砸了，也可以快速按一下顶栏Logo回首页再重新进入导览状态。另外我还在联系方式页做了一个“醒神”细节：表单提交按钮hover时有一个轻微的动效，现场讲到这里可以活跃一下气氛，投资人听完一堆严肃内容后往往就在这个环节放松下来。

5.3 第三方组件库的授权与“水印”问题

这次demo我几乎没引入重型第三方组件。唯一用到了一个图表库的开源版本（Apache 2.0协议），一个模拟数据的小工具，还有一个渲染Markdown的库。但很多团队做可视化官网demo时，会直接试装商业组件库的评估版。这里要特别提醒：商用图表库的试用版通常会在图表角落打上水印，而且官方协议明确禁止移除、遮挡或用CSS隐藏水印。有人动过“把水印裁掉”的歪脑筋，隐患很大，一旦上线被扫描到或用图被抓包，法律风险会落到产品头上。

我的建议是：demo阶段就选开源协议放心的库，Apache 2.0、MIT协议的中后台图表和组件都很丰富。假如一定要用某个商用库，解决方案要么是购买正式授权，要么跟厂商申请一个专门给演示的、无限制的评估许可。切忌通过破解、“去水印”脚本这类手段投机取巧，这对团队和客户都是负资产。

另外就是组件库的版本锁定。当时我同事在安装依赖时不小心把某个库从v2升到了v3，demo页面立刻出现几处样式不一致。排查了很久才发现是版本差异。从那以后，我在项目中把依赖锁定精确到补丁版本，并在构建流水线里加了npm ci（而不是npm install），保证团队任何人的本机构建产物一致。这也算是在demo实战中得来的教训。

6. 最后再分享一点个人心得

这个项目做完后，我最明显的一个感受是：demo的最终价值不在页面多精美，而在整个演示节奏是否连得起来。8个页面做得再好看，如果现场叙事断掉了，效果立刻打折。那条“+1”的演示故事线之所以重要，是因为它把一堆静态页面变成了一个有引导、有节奏的叙事工具。

再往后做类似项目，我会考虑加两件事：一是把案例详情也做成可通过URL参数直达的形式，方便把具体案例链接发给客户后他们直接点开；二是用一个简单的数据层（比如MSW这个库）模拟真实接口，让demo后期接真实API时不需要改前端代码结构。这两个扩展方向成本都不高，但收益很实在。

如果只留一条经验给你，那就是：demo项目的每一行代码都要有“会被现场演示放大”的自觉。那些平时看着无所谓的小瑕疵——图片没占位、刷新404、样式错乱、外部资源加载慢——在客户面前会被放得非常大。提前把所有资源本地化、按路由拆包、加上骨架屏、做一条演示故事线，这四件事做完，你的官网demo至少不会在关键时候掉链子。