餐厅官网响应式HTML源码：移动优先布局与交互实战-育师

简介：这份资源是面向前端学习者与中小型餐饮品牌建站需求的意大利风味餐厅响应式网页 HTML 源码，适合用于课程设计、作品集或官网原型练习，重点解决多终端适配与常见页面模块搭建问题。压缩包共 120 个文件，约 4.42MB，含 2 个 HTML 页面及 13 个 CSS、22 个 JavaScript 脚本，配合 PNG、JPG、SVG 等图片和多种字体文件，可直接预览并二次修改。样式与交互覆盖 Bootstrap 栅格、动画、图标字体、轮播、弹窗等常见方案，有助于理解桌面端到移动端的自适应布局、模块拆分和资源引用方式。已有 97 人学习下载，可从中梳理响应式页面结构、导航与展示区组织、交互插件配置及图片字体加载等前端实践要点，适合作为 H5 页面开发与餐饮类网站仿写的参考素材。

1. 一份餐厅官网源码，真正考验的是响应式能力

上周有人拿着这套意大利风味餐厅的 HTML 源码来问：页面在电脑上看着挺像样，一到手机上标题就压到图片上，菜单栏挤成两行，滚动时页面右边还多出一条白边。这类问题几乎每个做 web 前端静态页的人都遇到过——一套 html 源码能不能直接拿去交差，看的不是首页截图像不像，而是它在 375px 到 1920px 之间有没有一处布局出问题。这份餐厅响应式网页源码要解决的正是这件事：把一个餐饮品牌最常被访问的五类内容（首页、菜单、品牌故事、在线订位、到店信息）做成一套干净的前端 H5 静态结构，字号、间距、栅格随屏宽平滑缩放，移动端优先，桌面端加宽。它适合课程设计要一份完整成品的同学，也适合接小单的从业者拿它当改版基线——换配色、换菜品文案就能交付，不必从零搭骨架。

2. 需求拆解与技术选型：为什么这套页面不需要框架

2.1 餐厅类站点的真实访问场景决定了技术栈

做前端方案时，最忌讳的是项目还没想清楚就先往技术栈上堆。餐厅官网的访问数据有个很稳定的特征：移动端占比普遍在七成以上，且大量访问发生在「人已经在路上、马上要决定吃什么」的几分钟里。这意味着访问者的耐心极低，网络可能只是 4G 甚至更差，他们的目标只有四个：扫一眼菜品图、看价格、确认地址和营业时间、拨电话或订位。整个链路上没有任何需要登录、需要实时协作、需要复杂状态管理的环节。

把这个场景翻译成技术约束就很清楚了：首屏必须快，交互必须轻，离线容错要好，部署要简单到随便一台虚拟主机或静态托管就能跑起来。所以这类站点的正确选型就是原生 HTML + CSS + 现代 JavaScript，不引框架、不引构建工具、不引 UI 库。这不是「简单所以凑合」，而是需求本身就不匹配框架的收益模型——一个只有五个区块、十来个交互点的页面，引入打包器之后，构建配置的维护成本会超过业务代码本身。

我一般会跟做课设的同学强调：不要为了简历上好看而给餐厅页面套 Vue 或 React，答辩时被问「你为什么用框架」，答「因为大家都用」是最扣分的回答。反过来，如果你能讲清楚「移动优先的静态站点在这个场景下加载更快、依赖更少、改造成本更低」，这本身就是加分项。这套源码的定位就在这儿——它是一份可以直接跑的完整 web 前端成品，也是一个讲得清选型理由的基线。

2.2 三层文件结构：结构、样式、交互各归其位

拿到一份 HTML 源码包，先别急着改文案，先看它的文件是怎么划分的。合格的响应式站点通常遵循「结构层、样式层、交互层」三层分离，而且样式层还要再拆一层。因为餐厅页面有个典型特点：它由若干重复度很高的组件构成——菜品卡片、推荐位、图文分栏、页脚信息块，这些东西会在多个页面里反复出现。如果 CSS 全写在一个大文件里，改一个卡片的圆角就要担心有没有误伤别的地方。

我一般会把样式拆成四份，按加载顺序引用：base 负责重置与设计令牌，layout 负责容器、栅格、页头页脚这类骨架，components 负责卡片、按钮、表单、轮播这些可复用块，最后一份 page 只放某个页面独有的微调。这样改版的时候目标非常明确——客户说「菜品卡片太挤了」，你只需要动 components/menu-card.css，改完刷新，其他页面纹丝不动。这种可预测性在交付阶段比任何花哨效果都值钱。

交互层同理，一个文件只干一件事。导航开合、轮播、表单校验、滚动动画，各写一个几十行的模块，用 defer 顺序加载即可，不需要模块打包器。原生 ES Module 在现代浏览器上早就不是问题，但对这类小站点，直接多个 script 标签反而更省心——出问题时在 DevTools 的 Network 面板一眼就能看出是哪个文件没加载上。

2.3 目录、命名与资源规范

源码包的目录结构不需要多复杂，但一定要能让人在三秒内定位到想改的东西。下面这套是我在多个静态站点项目里反复用过的组织方式，和这份餐厅源码的工程结构是一致的：

restaurant-site/ ├── index.html # 首页：首屏 + 招牌菜 + 品牌简介 ├── menu.html # 菜单页：分类筛选 + 菜品网格 ├── about.html # 品牌故事：图文分栏 ├── booking.html # 在线订位：表单页 ├── contact.html # 到店信息：地图占位 + 营业时间 ├── assets/ │ ├── css/ │ │ ├── base.css # 重置、CSS 变量、字体 │ │ ├── layout.css # 容器、栅格、页头页脚 │ │ ├── components.css # 卡片/按钮/表单/轮播 │ │ └── page-home.css # 单页专属微调 │ ├── js/ │ │ ├── nav.js # 导航开合与断点复位 │ │ ├── carousel.js # 首屏轮播 │ │ └── booking.js # 表单校验 │ └── img/ │ ├── dishes/ # 菜品图，按 640/1280 两档导出 │ └── ui/ # 图标与装饰图 └── README.md # 改动说明：改了哪些文件、怎么换图

命名上我只守两条规矩：CSS 类名用 BEM 的简化版（块名在前，元素用双下划线，状态用 is- 前缀），图片文件名用小写加连字符并带尺寸后缀。前者让你在 HTML 里一眼看出某个类属于哪个组件，后者在做 srcset 的时候不用再猜哪张是缩略图。这两条看起来是小节，但在多人协作或者半年后自己回来看代码时，省下的时间相当可观。

提示：源码包里的图片如果只有一张大图，不要直接在<img>上写死宽高，先按 640 和 1280 两档导出，再配 srcset，后面第 4 章会讲具体写法。

资源体积上还有个容易被忽略的点：餐厅页面最占流量的永远是图片。一个菜品网格九张图，如果每张都是 400KB 的原图，首屏在移动网络下就要多等两三秒。通常的做法是所有菜品图统一压到 640px 宽、质量 75 左右，主视觉大图单独出一张 1280px 的，其余全部走懒加载。这套源码在资源组织上就是按这个思路铺的，改版时把新图按同样的规格丢进 dishes 目录，替换文件名即可，不用动 CSS。

3. 页面骨架与响应式布局：断点、栅格与移动优先的写法

3.1 语义化骨架决定后面所有布局的上限

很多人写响应式，一上来就调媒体查询，结果越调越乱。问题往往不在断点，而在 HTML 骨架本身就没有表达出内容的层级关系。餐厅首页天然可以切成五块：品牌与导航、首屏主视觉、招牌菜推荐、品牌故事简介、页脚信息（地址、电话、营业时间、社交入口）。这五块对应 header、带 hero 的 main、section、section、footer，用语义标签写出来，屏幕阅读器能读、搜索引擎能抓、你自己回头改布局时也知道哪段属于哪块。

下面这段是首页骨架的简化版，保留了响应式站点里真正起作用的部分：

<!-- index.html：语义化骨架，每个 section 只负责一段内容 --> <header class="site-header"> <a class="brand" href="index.html">意式小馆</a> <button class="nav-toggle" type="button" aria-expanded="false" aria-controls="site-nav" aria-label="打开导航"> <span class="nav-toggle__bar"></span> </button> <nav id="site-nav" class="site-nav" hidden> <ul class="nav-list"> <li><a href="menu.html">菜单</a></li> <li><a href="about.html">故事</a></li> <li><a href="booking.html">订位</a></li> <li><a href="contact.html">到店</a></li> </ul> </nav> </header> <main id="top"> <!-- 首屏：移动端文字压在图上，桌面端左右分栏 --> <section class="hero"> <div class="hero__media"> <img src="assets/img/ui/hero-1280.jpg" srcset="assets/img/ui/hero-640.jpg 640w, assets/img/ui/hero-1280.jpg 1280w" sizes="100vw" width="1280" height="720" alt="餐桌上的手工意面与红酒" fetchpriority="high" decoding="async"> </div> <div class="hero__copy"> <h1>每天现擀的手工意面</h1> <p>午市 11:30 开始，晚市至 22:00，可提前一天订位。</p> <a class="btn btn--primary" href="booking.html">在线订位</a> </div> </section> <section class="signature" aria-labelledby="sig-title"> <h2 id="sig-title">招牌推荐</h2> <div class="menu-grid"><!-- 菜品卡片由同一套结构复制 --></div> </section> </main> <footer class="site-footer"> <address>营业时间 11:30–22:00 · 订位电话见导航页</address> </footer>

这段骨架里有三个设计决策值得说。第一，首屏图片给了显式的 width 和 height，浏览器在图片下载完成前就能按比例占位，避免内容跳动把标题顶飞，这在移动端体验里差别巨大。第二，导航按钮用的是<button>而不是<div>，并且带 aria-expanded 和 aria-controls，键盘可以直接 Tab 到它并按回车展开，这是可访问性的最低要求，也是答辩时容易被追问的点。第三，移动端导航默认加 hidden 属性，由 JS 控制显隐，而不是靠 CSS 的 display: none 切——语义上更准确，也让「当前导航是开是关」有唯一可信来源。

3.2 断点与设计令牌：用变量把「一套样式适配所有屏」落到实处

响应式最容易犯的错是断点随手定：这里写 768，那里写 800，第三个文件又冒出 992。三个月后你想改一次导航的折叠时机，得全局搜索半天。正确做法是先把设计令牌集中声明一次，所有组件只引用变量，不写魔法数字。

/* assets/css/base.css —— 令牌集中管理，组件里禁止出现裸数值 */ :root { /* 色板：暖调砖红做主色，避免纯黑正文在米色背景上显得脏 */ --c-primary: #8a2b1f; --c-ink: #1f1b18; --c-muted: #6b625a; --c-cream: #faf6ef; --c-line: #e6ddd0; /* 间距用 clamp 平滑伸缩，手机到桌面不需要跳变 */ --space-1: clamp(0.75rem, 1.2vw, 1rem); --space-2: clamp(1.25rem, 2.4vw, 2rem); --space-3: clamp(2rem, 4vw, 3.5rem); /* 字号同理，4.2vw + 1rem 保证小屏不会小到看不清 */ --fs-h1: clamp(1.75rem, 4.2vw + 1rem, 3.25rem); --fs-h2: clamp(1.35rem, 2.2vw + 0.9rem, 2rem); --fs-body: clamp(0.95rem, 0.4vw + 0.85rem, 1.05rem); --radius: 14px; --maxw: 1180px; --ease: cubic-bezier(0.22, 0.61, 0.36, 1); } /* 基础排版只在这里定义一次 */ body { margin: 0; background: var(--c-cream); color: var(--c-ink); font-size: var(--fs-body); line-height: 1.7; -webkit-font-smoothing: antialiased; }

这里的关键是 clamp 的三个参数：最小值、随视口变化的中间值、最大值。它替代了大量「小于 480 一套、480 到 1024 一套、大于 1024 又一套」的字号媒体查询。好处是标题在任意宽度下都是连续变化的，不会出现「刚好跨过断点、标题突然大跳一格」的突兀感。参数怎么改：中间值里的 vw 系数控制伸缩速度，标题类一般给 2–5vw，正文类给 0.3–0.6vw；最大值决定桌面端上限，按设计稿量出来的字号填进去就行。

断点本身我只留三个：640px（手机横屏与小平板）、900px（导航折叠切换）、1024px（桌面栅格成型）。数量少的好处是心智负担低，你永远知道「当前处于哪一档」。

3.3 移动优先的栅格：默认单列，只做加宽

移动优先不是口号，是写法顺序：默认样式写给手机，媒体查询里只写 min-width。这样手机端拿到的 CSS 是最少的，也最不容易被后写的规则意外覆盖。

/* assets/css/components.css —— 菜品网格：手机单列，平板两列，桌面三列 */ .menu-grid { display: grid; gap: var(--space-2); grid-template-columns: 1fr; /* 默认：一列铺满 */ max-width: var(--maxw); margin-inline: auto; padding-inline: var(--space-2); } @media (min-width: 640px) { .menu-grid { grid-template-columns: repeat(2, 1fr); } } @media (min-width: 1024px) { .menu-grid { grid-template-columns: repeat(3, 1fr); } }

如果用 max-width 反着写，会出现一个典型问题：手机的默认样式其实继承自桌面，那些你没覆盖到的属性（比如某个卡片的内边距）会把移动端撑变形。min-width 顺序则天然安全，每加一档只是在原有基础上叠加。参数层面，gap 用 --space-2 而不是固定 px，是为了让间距跟字号一起伸缩——窄屏上 32px 的间距会显得空，宽屏上 16px 又太挤。

栅格列数的选择也有讲究。菜品卡片里有图有标题有价格，手机上两列会让菜名换行成两行、价格被挤到下一行；桌面三列是最舒服的密度，四列以上图片就小得看不清菜了。这种「列数由内容决定而不是由设备决定」的判断，是响应式设计和「把桌面版缩小」的本质区别。

3.4 汉堡菜单：一个组件里藏着的三个问题

移动端导航看起来是最简单的部分，实际上是最容易出问题的地方。要同时处理：展开动画、断点切换时的状态复位、点击链接后自动收起。

// assets/js/nav.js —— 导航开合，状态只存在 DOM 上 const toggle = document.querySelector('.nav-toggle'); const nav = document.getElementById('site-nav'); toggle.addEventListener('click', () => { const isOpen = toggle.getAttribute('aria-expanded') === 'true'; toggle.setAttribute('aria-expanded', String(!isOpen)); nav.hidden = isOpen; // 收起时置 true document.body.classList.toggle('is-nav-open', !isOpen); // 锁滚动用 }); // 点击任意导航项后自动收起，否则移动端会停在半开状态 nav.addEventListener('click', (e) => { if (e.target.closest('a') && window.matchMedia('(max-width: 899px)').matches) { nav.hidden = true; toggle.setAttribute('aria-expanded', 'false'); document.body.classList.remove('is-nav-open'); } }); // 断点复位：从手机宽度拉到桌面，导航必须强制展开，否则内容直接消失 const mq = window.matchMedia('(min-width: 900px)'); mq.addEventListener('change', (e) => { if (e.matches) { nav.hidden = false; toggle.setAttribute('aria-expanded', 'false'); document.body.classList.remove('is-nav-open'); } else { nav.hidden = true; } });

三个函数各管一件事，逻辑很直白，但每一条都是踩过坑之后加的。第一段里把开合状态读自 aria-expanded 而不是自己维护一个变量，好处是屏幕阅读器和 DOM 永远同步，不会出现「视觉上是开着的、aria 说关着」这种事。第二段处理的是移动端最常见的体验瑕疵——用户点完「订位」，页面跳转了但导航还开着，返回上一页时看到的是个半开的菜单。第三段是断点复位，也就是有人把手机横过来又转回去、或者在桌面浏览器里拖拽窗口宽度时，导航状态必须是确定的，不能靠运气。

is-nav-open这个类在 CSS 里的作用通常是给 body 加 overflow: hidden，防止背景跟着滚动。移动端菜单展开时如果背景还能滚，手指一滑页面就跑到下面去了，菜单浮在半空，非常难受。这段 CSS 通常这样写：

/* 菜单展开时锁住背景滚动，关闭时立即恢复 */ body.is-nav-open { overflow: hidden; } @media (min-width: 900px) { .nav-toggle { display: none; } /* 桌面端隐藏汉堡按钮 */ .site-nav { display: block; } /* 桌面端永远展开 */ }

注意桌面端的 display: block 和 JS 里的 hidden 属性是有优先级冲突的——hidden 属性默认等价于 display: none，但作者样式里的 display: block 会覆盖它。这正是为什么上面 JS 的断点复位里要显式把 nav.hidden 设成 false，两处配合才不会互相打架。这类「CSS 和 JS 抢同一个元素的显隐权」的情况，是静态页面里最常见的一类隐性 bug。

4. 视觉与交互模块：菜单卡片、首屏轮播与预订表单

4.1 菜品卡片：图文比例和加载策略一起定

菜品卡片是这套页面的信息密度核心，也是最容易被做得难看的地方。难点在于图片比例不统一——有的菜是横构图，有的是竖构图，如果只写 width: 100%，卡片高度会参差不齐，栅格看起来像被啃过。解决办法是给图片容器固定宽高比，图片用 object-fit: cover 裁切，让所有卡片保持一致的节奏。

/* 卡片结构：媒体区固定比例，文案区自然撑高 */ .menu-card { background: #fff; border: 1px solid var(--c-line); border-radius: var(--radius); overflow: hidden; /* 让圆角能裁到图片 */ transition: transform 0.35s var(--ease), box-shadow 0.35s var(--ease); } .menu-card__media { aspect-ratio: 4 / 3; /* 关键：统一宽高比 */ background: var(--c-line); /* 图片未加载时的占位色 */ } .menu-card__media img { width: 100%; height: 100%; object-fit: cover; /* 裁切而不拉伸 */ display: block; } .menu-card__body { padding: var(--space-2); } .menu-card__price { font-variant-numeric: tabular-nums; /* 价格数字等宽对齐 */ color: var(--c-primary); font-weight: 600; }

配套的 HTML 里，图片要带 srcset、sizes 和 loading="lazy"：

<article class="menu-card"> <div class="menu-card__media"> <img src="assets/img/dishes/truffle-pasta-640.jpg" srcset="assets/img/dishes/truffle-pasta-640.jpg 640w, assets/img/dishes/truffle-pasta-1280.jpg 1280w" sizes="(min-width: 1024px) 33vw, (min-width: 640px) 50vw, 100vw" width="640" height="480" loading="lazy" decoding="async" alt="黑松露奶油宽面"> </div> <div class="menu-card__body"> <h3>黑松露奶油宽面</h3> <p>现擀宽面、黑松露酱、帕玛森芝士碎。</p> <span class="menu-card__price">¥ 88</span> </div> </article>

sizes 属性是这里最容易被忽略、收益又最大的一行。它在告诉浏览器「这张图在当前布局下大概占多宽」，浏览器据此从 srcset 里挑合适的那档下载。如果写错成 100vw，桌面端三列布局下浏览器会傻乎乎地下载 1280px 的大图，白白多花一倍流量。写法要和第 3.3 节的栅格列数严格对应：三列就是 33vw，两列 50vw，单列 100vw。改了栅格不改 sizes，是性能下降却看不出问题的典型原因。

4.2 首屏轮播：能不加库就不加库

很多餐厅模板会给首屏放一个自动轮播，配左右箭头加圆点。原生的做法不需要任何第三方库：结构上用一个横向滚动容器，CSS 加 scroll-snap 让每一屏自动吸附，JS 只负责定时滚动和同步圆点状态。

/* 首屏轮播：滚动吸附 + 隐藏滚动条，触摸滑动天然可用 */ .hero-slider { display: flex; overflow-x: auto; scroll-snap-type: x mandatory; scrollbar-width: none; /* Firefox */ } .hero-slider::-webkit-scrollbar { display: none; } .hero-slider__item { flex: 0 0 100%; scroll-snap-align: start; /* 每次停在一屏起点 */ } /* 尊重系统的「减少动态效果」偏好 */ @media (prefers-reduced-motion: reduce) { .hero-slider { scroll-behavior: auto; } }

// assets/js/carousel.js —— 只做定时推进与圆点同步，逻辑保持极薄 const slider = document.querySelector('.hero-slider'); const dots = [...document.querySelectorAll('.hero-dots button')]; function goTo(index) { const item = slider.children[index]; slider.scrollTo({ left: item.offsetLeft, behavior: 'smooth' }); } // 用 IntersectionObserver 判断当前停在哪一屏，比监听 scroll 省性能 const io = new IntersectionObserver((entries) => { entries.forEach((entry) => { if (!entry.isIntersecting) return; const i = [...slider.children].indexOf(entry.target); dots.forEach((d, di) => d.setAttribute('aria-current', String(di === i))); }); }, { root: slider, threshold: 0.6 }); [...slider.children].forEach((el) => io.observe(el)); // 用户手动滑动后暂停自动播放，避免「刚滑走又被拽回去」 let timer = setInterval(() => { const next = (slider.scrollLeft + slider.clientWidth) % slider.scrollWidth; slider.scrollTo({ left: next, behavior: 'smooth' }); }, 5000); slider.addEventListener('pointerdown', () => clearInterval(timer), { once: true });

设计上有个取舍值得讲：为什么用 scroll-snap 而不是常见的 translateX + 索引位移？因为前者在移动端天然支持手指滑动，还带惯性，你不用写一行触摸事件代码；而且滚动位置是浏览器的原生状态，不会出现「JS 索引和实际视觉位置不一致」的情况。代价是自动播放的推进逻辑要基于 scrollLeft 计算，稍微绕一点，但稳定性高得多。中间那段 IntersectionObserver 用 0.6 的阈值判断当前屏，比监听 scroll 事件再算位置省下大量重排开销，这是这类页面里性能上最划算的一笔交易。

参数怎么调：自动播放间隔 5000ms 是我一般会给餐厅页面的值，短于 3 秒用户根本看不清菜品，长于 8 秒又显得页面是死的。threshold 0.6 意思是「这一屏有六成进入视口」才算当前屏，避免两屏交界处圆点来回闪。

4.3 预订表单：校验逻辑写在用户出错之前

订位表单是这套页面里唯一有「业务规则」的模块，规则不多但每条都有实际意义：日期不能选过去的、人数限定在 1 到 12、电话要能过基本的格式校验。好的表单设计不是在提交后弹一堆红字，而是在用户动手之前就把不可能的选项排除掉。

// assets/js/booking.js —— 先约束输入范围，再做提交校验 const form = document.querySelector('.booking-form'); const dateInput = form.elements.date; const peopleInput = form.elements.people; // 过去日期在移动端日期选择器里极易误选，直接把 min 设成今天 dateInput.min = new Date().toISOString().slice(0, 10); form.addEventListener('submit', (e) => { e.preventDefault(); const errors = []; if (!dateInput.value) { errors.push('请选择到店日期'); } else if (dateInput.value < dateInput.min) { errors.push('到店日期不能早于今天'); } const n = Number(peopleInput.value); if (!Number.isInteger(n) || n < 1 || n > 12) { errors.push('用餐人数支持 1–12 人，更多请致电门店'); } // 电话只做宽松校验：允许空格、连字符，避免误杀正常输入 const phone = form.elements.phone.value.replace(/[\s-]/g, ''); if (!/^1[3-9]\d{9}$/.test(phone)) { errors.push('请填写 11 位手机号'); } const box = form.querySelector('.form-errors'); box.innerHTML = errors.map((msg) => `<li>${msg}</li>`).join(''); box.hidden = errors.length === 0; if (!errors.length) { // 静态站点没有后端，这里通常是跳转到成功提示或对接表单服务 form.querySelector('.form-success').hidden = false; form.reset(); } });

几个细节说明。日期用 min 属性做约束，而不是只在提交时判断——移动端原生日期选择器会直接灰掉不可选的日期，用户根本点不到过去的日期，这比事后报错友好得多。人数上限设 12 是从业务出发的：超过这个数属于团体用餐，需要电话沟通，表单不该承接。电话校验故意用了宽松的正则，因为强行要求「必须 11 位纯数字」会把带空格或连字符的输入误判成错误，用户会觉得很莫名其妙。

错误提示的渲染方式也值得注意：清空再重建，而不是逐条 append。因为用户第二次提交时，上一次的错误如果没清干净，会叠加成两遍。box.hidden = errors.length === 0这一行则保证没有错误时这个容器彻底不占位，不会在表单下面留一块空白。

注意：静态页面本身无法真正发送订位请求。交付时要么接一个第三方表单服务，要么明确告知客户「提交后由店员电话确认」，不要在页面上写「已收到您的订位」这种无法兑现的反馈。

4.4 滚动入场动画：动效服务于信息层级，不是炫技

餐厅页面加一点入场动画是合理的——菜品从下方淡入，能让用户在滚动时注意力落在当前区块上。但这类页面最常见的失误是动画太多太重，一屏十几个元素每个都从不同方向飞入，滚动起来像开盲盒。

我一般只用一种动效：透明度 0 到 1，配上 16px 的向上位移，时长 400ms 左右，用 IntersectionObserver 触发一次即解除监听。

/* 默认可见，只有 JS 正常工作时才隐藏，保证禁用脚本也不会白屏 */ .js-ready .reveal { opacity: 0; transform: translateY(16px); transition: opacity 0.4s var(--ease), transform 0.4s var(--ease); } .js-ready .reveal.is-in { opacity: 1; transform: none; } @media (prefers-reduced-motion: reduce) { .js-ready .reveal { opacity: 1; transform: none; transition: none; } }

这段 CSS 有个关键设计：隐藏规则挂在一个由 JS 添加的js-ready类下面。如果脚本加载失败或被用户禁用，页面元素默认就是可见的，不会出现「一片空白、什么都没显示」的灾难。这条经验来自一次真实的翻车——早期版本直接写.reveal { opacity: 0 }，结果某个环境里 JS 报错导致整页内容全部隐形，用户看到的是一张背景图加空白。从那以后我所有动效的初始隐藏态都挂在 JS 添加的类下面。

prefers-reduced-motion那段也不是可选项。部分用户因为前庭功能原因会对位移动画不适，系统层面开了「减少动态效果」之后，页面应当直接给最终态。这是一行代码的成本，换来的是无障碍体验的完整。

5. 常见问题排查：响应式页面最容易出现的五个问题

5.1 现象：手机上首屏高度忽高忽低，滚动时内容乱跳

现象很典型：页面刚打开时首屏铺满，手指一滑，浏览器地址栏收起，首屏突然变高，下面的内容被顶下去一截，再滑回来又弹回去。用 100vh 写全屏首屏的页面几乎必然遇到这个问题。

原因是移动浏览器的 vh 单位按「地址栏隐藏时的最大视口高度」计算，与实际可视高度并不一致。这个差值在部分机型上能到 80px 以上，足够把一屏内容推歪。

解决方式是用动态视口单位 svh / dvh 替代 vh，或者干脆不追求严格全屏：

/* 用 min-height 而不是固定 height，并给 vh 留一个降级值 */ .hero { min-height: 88vh; /* 老浏览器降级 */ min-height: 88svh; /* 新浏览器：按最小可视高度算，地址栏收放都不跳 */ }

如果项目必须兼容较老的设备，另一种稳妥做法是把首屏高度交给内容决定，图片用 aspect-ratio 撑开，完全不用 vh。牺牲一点点「刚好铺满」的视觉，换来的是任何机型上都不跳动——这类页面里，稳定性比那一点点视觉收益重要得多。

5.2 现象：页面右边多出一条横向滚动条，手机上还能左右晃

这是响应式排查里的第一高频问题。表现是页面内容明明没超宽，但整页可以左右滑动，右边留出一条白边，有时手机上还会出现页面被整体缩小的情况。

原因通常有三个，按出现频率排序：某个元素的宽度用了 100vw 并带 padding（vw 不含滚动条宽度，加起来就溢出）；某个绝对定位的装饰元素跑到了容器外面；某个长英文单词或链接撑破了父容器。排查方法很直接，在 DevTools 控制台跑一行：

// 找出所有右边界超出视口的元素，一次性定位元凶 [...document.querySelectorAll('*')].filter(el => { const r = el.getBoundingClientRect(); return r.right > document.documentElement.clientWidth + 1; }).forEach(el => console.log(el, el.getBoundingClientRect().right));

对应的三种修法：把 100vw 换成 100%（百分比是基于父容器，不含滚动条）；给溢出的绝对定位元素加 overflow: hidden 的父容器；给长文本加 overflow-wrap: break-word。还有一种更省事的兜底写法，在 html 上加overflow-x: hidden——但我不推荐把它当首选，因为它只是把溢出藏起来了，真正的问题（比如某个区块被裁掉一半）还在，只是你看不见。

5.3 现象：改了媒体查询断点，交互还是旧逻辑

这个问题的隐蔽性很高：CSS 里导航的折叠断点从 768px 改成了 900px，样式上看着对了，但在 800px 宽度下点汉堡按钮没反应，或者反过来桌面布局下导航被藏起来了。

原因是断点在两处各写了一份——CSS 的媒体查询里一份，JS 的 matchMedia 里一份。改了一处忘了另一处，两者就对不上。这在接手别人代码或者自己隔了几个月回来改的时候几乎必然发生。

解决思路是把断点收敛成单一来源。样式侧继续用媒体查询（CSS 没法读 JS 常量），但要在 base.css 顶部写一段注释，列出全部断点及其用途，JS 里的 matchMedia 值必须与之一一对应；更彻底的做法是让 JS 读取一个 CSS 自定义属性做判断：

// 从 CSS 变量读断点，保证 JS 与 CSS 用的是同一个数字 const bp = parseInt( getComputedStyle(document.documentElement).getPropertyValue('--bp-md'), 10 ); const mq = window.matchMedia(`(min-width: ${bp}px)`);

配套在 :root 里声明--bp-md: 900px;。这样以后改断点只改一个地方，JS 自动跟上。代价是多一次样式计算，但页面加载时执行一次，开销可以忽略。我在任何超过三个断点的项目里都会用这种方式，血泪经验换来的一行代码。

5.4 现象：本地看着好好的，换台设备字体和图片全变样

表现为换到另一台电脑或手机上，标题字体变成了系统默认的宋体或衬线体，图片要么被拉扁要么模糊，整体观感跟本地完全不同。

字体的问题通常是只写了 font-family: "某字体" 而没有回退链，或者引用了系统里恰好有、别人机器上没有的本地字体。正确做法是给出完整的回退链，并且优先使用系统字体栈，需要特殊字体时用 font-display: swap 避免文字长时间不可见：

/* 回退链：先特殊字体，再通用衬线，最后兜底到系统默认 */ .hero__copy h1 { font-family: "Playfair Display", Georgia, "Times New Roman", serif; font-display: swap; }

图片的问题多出在两处：一是没有设置 width/height，不同设备的默认渲染尺寸不同；二是只给了固定像素宽高却在 CSS 里用百分比拉伸，导致清晰度损失。解决办法就是第 4.1 节那套写法——HTML 上写真实像素宽高作为比例参考，CSS 上限定 width: 100%、height: 100% 配 object-fit，两处配合才能在各种 DPR 的屏幕上都不失真。

5.5 现象：iOS 上点开输入框，整个页面被放大且回不去

移动端表单最典型的问题：在 iPhone 上点一下手机号输入框，页面突然放大，输入完之后页面停留在放大状态，需要双指捏回来。用户会以为页面出了问题。

原因是 iOS Safari 有一条规则——输入框的字体小于 16px 时，聚焦会自动放大页面。很多设计稿为了精致把输入框字号设成 14px，就正好触发了这条规则。

修法只有一条，而且必须照做：所有 input、select、textarea 的 font-size 在移动端不小于 16px。

/* iOS 聚焦防缩放：移动端表单控件字号不低于 16px */ @media (max-width: 899px) { .booking-form input, .booking-form select, .booking-form textarea { font-size: 16px; } }

这里不要用user-scalable=no去禁止缩放，那会连带禁掉用户主动放大阅读的能力，属于用错误解决问题。字号改到 16px 之后，输入框看起来会比设计稿略大一点，通常的处理是把 padding 相应减小，视觉上仍然协调。这个坑几乎每个做移动端表单的人都踩过一次，记住这条规则之后就不会再犯。

6. 验收与答辩：怎么证明这套页面在各种屏幕上真的站住了

交付前我一定会做一遍固定动作，叫「五档走查」。打开 DevTools 的设备模拟，依次调到 375、414、768、1024、1440 五个宽度，每个宽度只检查四件事：有没有横向滚动条、导航是否正常开合、图片有没有变形或被裁掉关键部分、文字有没有压到图片上。这五档覆盖了主流手机、平板和桌面，绝大多数布局问题在这五个宽度里都会暴露出来。走查时不要只看首页，五个页面挨个过一遍，尤其注意表单页和菜单页——这两个页面的元素最多，出问题的概率最高。

真机验证不能省。模拟器不会告诉你 iOS 的输入框缩放问题，也不会告诉你安卓上滑到页面底部时地址栏的行为。至少在一台 iPhone 和一台安卓上分别打开首页、菜单页、订位页，重点做三件事：滑动首屏看有没有跳动、点开表单输入框看有没有放大、把手机横过来看布局有没有崩。这些动作加起来不超过五分钟，但能挡掉答辩现场最尴尬的几类问题。

答辩或者交付评审时，我建议按下面这个顺序讲，比从「我用了什么技术」开始讲有效得多：

环节	讲什么	拿什么证明
需求	餐厅访客七成在手机上，目标是看菜单、订位、找到店	页面信息架构图，五个页面的职责划分
选型	静态 HTML + CSS + 原生 JS，无框架无构建	首屏资源体积、请求数、无依赖的说明
布局	移动优先，三个断点，clamp 做连续伸缩	现场拖拽窗口宽度，展示布局平滑变化
交互	汉堡菜单、轮播、表单校验各自独立成模块	现场演示移动端菜单开合与断点复位
验收	五档走查 + 双真机验证	走查记录表，逐项打勾