去年帮一个做适老化改造的团队收拾过一个半成品站点用的就是一套黄色养老院网站模板。视觉上挺讨喜暖黄配米白看着有温度结果上线三天就收到家属反馈字太小看不清、按钮点不中、手机上打开首屏就是一整块黄。那次返工让我意识到黄色调在养老类站点里不是好看就行的事它同时牵着色觉识别、对比度、触控热区一整套硬指标任何一项没算准模板再漂亮也是白搭。这篇内容想聊的就是这件事一套以黄色为主色的养老机构网站模板从配色决策、信息架构、适老化交互、首页模块拆解、移动端性能到上线排错完整走一遍。适合两类人看——手里已经拿到一套模板、想把它改到能真正交付的前端以及要给机构做官网、但不确定适老化到底该落到哪些具体参数上的开发者。文中所有数值、代码和排查思路都来自实际改版过程能直接抄。1. 黄色主色在养老场景里的真实作用很多人拿到这套模板的第一反应是换个色不就行了其实黄色在这里承担的任务比想象中多。它不只是品牌色还是导航锚点、状态提示和情绪暗示的载体。三个任务混在一起就决定了你不能随便挑一个 #FFD700 就往 CSS 里塞。1.1 黄色在这里要同时干三件事第一件事是视觉锚定。养老院官网的访客里中老年用户占比很高他们对高饱和度暖色的敏感度普遍好于冷色系黄色在页面里做按钮、做当前导航项、做立即预约这类行动点识别的成本最低。第二件事是情绪传达暖黄加米白传递的是阳光、有人气、不冷清这跟机构想塑造的形象是对得上的换成蓝灰就变成医院感了。第三件事是区域分隔模板里大量用浅黄底块来切分不同的信息区块比单纯画灰色分割线更柔和。问题就在这三件事对黄色的要求是矛盾的。做锚点要饱和、要跳做情绪底色要淡、要大面积做分隔要低对比、不能抢内容。所以一套成熟的模板里黄色从来不是一个颜色而是一条完整的色阶从近白的浅黄到偏褐的深黄每一档对应一种用途。我在改版时把色阶压到了五档够用且不容易乱。超过五档维护的人自己都记不住哪个该用在哪。1.2 从色卡到 CSS 变量一份能直接用的色阶表具体数值是这样的命名按 50 到 700 递进跟常见设计系统的习惯保持一致方便交接:root{ /* 品牌黄从浅到深 */ --brand-50: #FFF9E6; /* 页面大面积底色、区块背景 */ --brand-100: #FFF1C2; /* 卡片悬停、表格斑马纹 */ --brand-300: #FFD75E; /* 次级按钮、标签、图标底 */ --brand-500: #F5B301; /* 主按钮、当前导航、强调数字 */ --brand-700: #8A5E00; /* 黄色底上的深色文字、边框 */ /* 中性色刻意偏暖避免和黄色打架 */ --ink-900: #2B2A28; --ink-600: #5A5751; --ink-300: #B8B4AC; --paper: #FFFDF7; --radius: 12px; --shadow-soft: 0 2px 10px rgba(138,94,0,.08); }这里有两个容易被忽略的细节。一是--paper没有用纯白#FFFFFF而是用了略带暖调的#FFFDF7。纯白和浅黄并排时浅黄会显得脏暖白能把两者黏合起来整页看起来是一体的。二是中性色全部偏暖--ink-900是#2B2A28而不是#333333因为纯灰文字压在黄底上会有明显的发青错觉暖灰读起来更舒服。提醒色阶一旦定下来就写进项目根目录的一份tokens.css所有组件只准引用变量不准写死十六进制。这是后面能把这套模板复用给第二家机构的前提。1.3 对比度是黄色最容易翻车的地方黄色最大的陷阱是明度高。人的眼睛对高明度色的细节分辨力会下降白字压在黄底上几乎是灾难。我实测过几组常见组合按 WCAG 的相对亮度公式算对比度结果如下前景色背景色对比度判定#FFFFFF白字#F5B301主黄约 1.8:1不合格几乎不可读#2B2A28深墨#F5B301主黄约 9.6:1优秀正文可用#5A5751暖灰#FFF9E6浅黄约 6.4:1合格辅助文字可用#8A5E00深褐#FFF1C2次浅黄约 5.1:1合格标签与小字可用#F5B301主黄#FFFDF7暖白约 1.9:1不合格不能做文字色结论很直接黄色永远当背景深色永远当文字。主按钮的写法应该是黄底 深墨字而不是常见的彩色底 白字。这条规则看起来反直觉但只要你在手机屏幕上把白字黄底放到户外光线下看一眼就不会再犹豫。对比度的计算其实不难相对亮度是对每个通道做 gamma 反校正后加权求和权重分别是 0.2126、0.7152、0.0722最后用(L10.05)/(L20.05)得出比值。写个十几行的小脚本跑一遍比肉眼猜靠谱得多。我当时是把手上的候选色全丢进脚本批量算一次筛掉了一半。还有一条经验黄色区块不要挨着另一个黄色区块。两个不同明度的黄贴在一起边界会融化中老年用户分不清这是两块内容还是一块。中间必须夹一条暖白间隙或者一条--brand-700的细边。2. 从访客诉求倒推页面清单模板到手时通常已经带了十几个页面但里头有一半是凑数的。我的做法是先不管模板给了什么坐下来把访客分成几类看他们第一眼想找什么再决定哪些页面留、哪些砍。2.1 三类访客三种完全不同的路径家属是主要决策者通常三四十岁在手机上搜附近养老院最关心的是离得远不远、多少钱、护理等级怎么分、能不能先去看看。他们的路径短一般两三次点击内就要么打电话要么填表。老人本人偶尔会自己看关注点更具体吃得好不好、有没有活动、房间朝南不朝南他们看得慢需要大字和图片。合作方社区、康复机构、渠道关心的是资质、床位规模和对接方式人数少但价值高需要一个能下载资料的入口。把这三条路径画出来之后页面清单基本就定了。首页要同时承载家属的行动入口和老人的信任建立房型与收费必须独立成页因为这是家属的核心决策依据院内环境用相册承担视觉说服预约参观做成一个轻量表单不要做成注册流程。2.2 站点地图与栅格约定最终留下的页面是七个首页、机构介绍、房型与收费、护理服务、院内环境、常见问题、预约参观。多出来的新闻中心人才招聘我建议先砍掉——模板里这两个页面通常只有三条占位新闻上线后半年不更新反而显得机构没人管。真要放等有内容了再加。栅格用 12 列容器最大宽度 1200px两侧留白在 1024px 以下降到 24px768px 以下降到 16px。这个约定写进 CSS.container{ width: min(100% - 48px, 1200px); margin-inline: auto; } media (max-width: 768px){ .container{ width: calc(100% - 32px); } }margin-inline和width: min()这套写法现在已经很稳了比老的margin: 0 auto加媒体查询少一半代码也不会出现横向滚动条。2.3 目录结构为二次交付提前留位这套模板我后来复用给了另外两家机构所以目录结构从一开始就是按可替换设计的/site /assets /css tokens.css # 色阶、字号、间距只改这里就能换主题 base.css # 重置、排版、通用工具类 components.css # 按钮、卡片、表格、表单 pages.css # 各页面专属样式 /js main.js # 导航、滚动、灯箱 form.js # 表单校验与提交 /img /raw # 原图不进构建 /web # 压缩后的 webp jpg 兜底 /index.html /rooms.html /services.html /gallery.html /faq.html /booking.html /about.html关键点是tokens.css单独抽出来并且pages.css里绝不允许出现十六进制颜色。这条规矩听着死板但它决定了后面换色是十分钟还是两天。3. 适老化交互的硬指标怎么定适老化这三个字最容易被做成口号——加个字号切换按钮就算交差。真正落到代码上它是几个可以量出来的数字基准字号、行高倍数、点击热区尺寸、动效时长上限。3.1 基准字号和行高是算出来的不是拍的模板原始的根字号是 16px正文 14px行高 1.5。这个配置在普通站点没问题但在养老场景里偏小。我最终的取值是根字号 18px正文继承根字号行高 1.75段落间距 1em。为什么是 18px参考的是移动端正文可读性的一般结论中老年用户在 375px 宽的手机上正文低于 17px 时阅读速度明显下降而超过 20px 会导致每行字数过少、频繁换行反而疲劳。18px 落在这个区间的中间偏上同时能保证 375px 宽下每行大约 18 到 22 个汉字是一个比较舒服的密度。行高 1.75 的理由不太一样。行高偏小时读者从一行末尾回到下一行行首容易串行这个现象在视力下降后会更明显。1.75 倍的间距给了眼睛足够的回程余量同时又不至于让段落松散到失去整体感。标题层级也跟着放大但比例要收敛。原始模板是 48/36/24/18 的跨度我压成了 40/32/24/18也就是标题之间的差距变小了。因为大字号在窄屏上会挤成两三行跨度太大的话页面节奏会变得很碎。html{ font-size: 18px; } body{ font-size: 1rem; line-height: 1.75; color: var(--ink-900); background: var(--paper); } h1{ font-size: clamp(1.75rem, 1.2rem 2vw, 2.25rem); line-height: 1.3; } h2{ font-size: clamp(1.4rem, 1.1rem 1.2vw, 1.75rem); line-height: 1.35; } h3{ font-size: 1.15rem; line-height: 1.5; } p{ margin-block: 0 1em; }clamp()在这里很省事标题能随视口平滑缩放不用写一堆断点。注意clamp的中间项用了rem vw的混合写法这是为了避免纯vw在超大屏上把标题撑得过大。3.2 触控热区44 像素是底线不是目标按钮尺寸这块行业里常提的最小触控目标是 44×44 CSS 像素。实际做下来44 只能算底线养老场景建议做到 48 以上主行动按钮拨号、预约做到 52 以上更稳妥。除了尺寸间距同样重要。两个按钮紧挨着即使各自都有 48px 高手指落点偏一点还是会点错。我定的规则是相邻可点击元素之间的间隙不小于 12px主次按钮并排时不小于 16px。导航栏是这个规则最容易失守的地方。原始的顶部导航在 768px 以下会缩成汉堡菜单展开后每一项高度只有 40px 左右密排在一起。我改成了每项最小高度 56px项与项之间加一条 1px 的浅黄分隔线视觉上更清楚误触也少了。.nav-list a{ display: flex; align-items: center; min-height: 56px; padding-inline: 20px; font-size: 1.05rem; color: var(--ink-900); } .nav-list a[aria-currentpage]{ background: var(--brand-100); box-shadow: inset 4px 0 0 var(--brand-500); }用inset阴影做左边框是为了不改变盒模型宽度避免布局跳动。当前页的标识同时用了底色和左边条两种手段因为只靠颜色深浅区分对色觉不敏感的用户不够友好。3.3 动效收敛和无障碍属性模板自带的滚动入场动画是每个区块淡入 上移 40px还带了一点缩放。这套效果在营销站上没问题但在这个场景里有两个毛病一是滚动到一半内容还是半透明的老人会以为页面没加载完二是动画时长 800ms 偏长连续滚动时会有明显的追不上手的感觉。我把时长压到 240ms位移减到 12px去掉缩放并且加上系统级的动效偏好判断media (prefers-reduced-motion: reduce){ *, *::before, *::after{ animation-duration: .01ms !important; transition-duration: .01ms !important; } }无障碍属性这块实话说原始的黄色模板做得比较糙——一堆div当按钮用图片全没有alt表单的label跟输入框没有关联。改造成本不高但收益明显尤其是对用读屏软件的用户。具体做了几件事所有可点击的非a/button元素要么换成语义标签要么补role和tabindex所有内容图片补alt纯装饰图alt表单的label用for绑定id折叠菜单加aria-expanded。4. 首页各模块的拆解与实现首页是这套模板里改动最大的地方原因很实际家属在手机上进来首屏看不到关键信息就会走。下面按从上到下的顺序把几个核心模块的处理方式说清楚。4.1 顶部导航与吸底拨号条桌面端是常规的左侧 Logo 右侧导航Logo 区用--brand-50打底跟页面主体做一点区分。真正重要的是移动端模板原本只做了汉堡菜单我额外加了一条吸底拨号条固定在屏幕底部左边是电话咨询右边是预约参观。这条吸底条是整个改版里转化提升最明显的部件。原因很简单——中老年用户不习惯在网页里填表他们更愿意直接打电话而拨号入口如果藏在菜单里多一步就会流失一批人。实现上用了position: fixed加上padding-bottom: env(safe-area-inset-bottom)来适配全面屏底部的手势区.call-bar{ position: fixed; inset: auto 0 0 0; display: grid; grid-template-columns: 1fr 1fr; gap: 12px; padding: 10px 16px calc(10px env(safe-area-inset-bottom)); background: rgba(255,253,247,.94); backdrop-filter: blur(8px); border-top: 1px solid var(--brand-100); z-index: 50; } media (min-width: 1024px){ .call-bar{ display: none; } }同时 body 要补一个padding-bottom值等于吸底条的高度含安全区否则页面最底部的内容会被永久遮住。这个细节我第一次就漏了结果常见问题页最后一条永远看不全。还有一个坑吸底条上的拨号链接用hreftel:...在某些内嵌浏览器比如从社交软件里点开的页面里不会直接唤起拨号而是弹一个提示。这种情况下需要在按钮旁边保留一个复制电话的次要操作长按复制对老人来说反而更难所以又加了一句点击号码复制的小字提示。4.2 首屏横幅黄色叠加图片的可读性处理原始首屏是一张大图 白色标题压在图上图片本身偏亮白字基本看不清。我改成了双层结构底层图片上层一层从--brand-700到透明的渐变遮罩标题用暖白字副标题用--brand-100。遮罩的方向和浓度需要调。纯黑遮罩会把图片压死失去明亮的感觉用深褐--brand-700的暗化版本更协调.hero{ position: relative; isolation: isolate; } .hero img{ width: 100%; height: clamp(320px, 52vh, 560px); object-fit: cover; } .hero::after{ content: ; position: absolute; inset: 0; background: linear-gradient( 100deg, rgba(90,62,0,.82) 0%, rgba(90,62,0,.55) 42%, rgba(90,62,0,.10) 75% ); } .hero-content{ position: relative; z-index: 1; color: #FFFDF7; }isolation: isolate这行是为了让伪元素的层级只在本区域内生效避免跟页面其他z-index打架这个坑我在另一个项目里踩过——不加的话遮罩偶尔会盖到吸底条上面去。首屏文案只放三样东西一句话说清机构定位、一行补充信息床位数、位置、成立年限、一个主按钮。模板原本放了五条卖点小图标在手机上全挤在首屏下方反而把主按钮挤出了可视区。这类卖点罗列移到第二屏更合适。4.3 房型表格让家属能横向对比房型与收费是决策页模板给的是一个三列卡片布局每张卡片写房型、面积、价格。问题在于卡片无法横向对比家属要来回扫视。我改成了表格并且做了一件事把最关键的两列护理等级、月费区间固定在左侧其余列在窄屏上横向滚动。房型护理等级月费区间面积床位数朝向双人间自理面议约 22 ㎡2南 / 东双人间半自理面议约 22 ㎡2南 / 东单人间自理面议约 16 ㎡1南护理间全护理面议约 26 ㎡3东南价格一栏我统一写面议这是个务实的选择。养老机构的收费跟护理等级、餐费、押金强相关网上写一个具体数字家属到店后发现不一样反而增加沟通成本。表格旁边配一句具体费用以到院评估为准把预期先框住。表格的移动端处理用了容器横向滚动 首列吸附.table-wrap{ overflow-x: auto; -webkit-overflow-scrolling: touch; } .table-wrap th:first-child, .table-wrap td:first-child{ position: sticky; left: 0; background: var(--brand-50); z-index: 1; }-webkit-overflow-scrolling现在基本是历史遗留了加上也不影响主要是为了照顾一些老版本的内嵌浏览器。4.4 环境相册灯箱要能单手操作相册模块用的是 CSS Grid 瀑布式布局桌面上三列平板两列手机上两列但不做高度错落错落在窄屏上会让滚动很跳。点击放大用的是一个轻量灯箱自己写的没引第三方库因为需要的东西很少全屏遮罩、左右切换、关闭按钮、键盘 Esc 支持。单手操作这点值得单独说。灯箱的关闭按钮如果放在右上角右手单手持机时够起来很别扭。我把它放在了右下角同时保留点击遮罩关闭切换按钮放在底部居中偏两侧拇指刚好覆盖。const lb document.querySelector(.lightbox); const imgs [...document.querySelectorAll(.gallery img)]; let idx 0; function open(i){ idx i; lb.querySelector(img).src imgs[idx].dataset.full; lb.hidden false; document.body.style.overflow hidden; } function close(){ lb.hidden true; document.body.style.overflow ; } function step(d){ idx (idx d imgs.length) % imgs.length; lb.querySelector(img).src imgs[idx].dataset.full; } lb.addEventListener(click, e { if (e.target.matches([data-close])) close(); if (e.target.matches([data-prev])) step(-1); if (e.target.matches([data-next])) step(1); }); document.addEventListener(keydown, e { if (lb.hidden) return; if (e.key Escape) close(); if (e.key ArrowLeft) step(-1); if (e.key ArrowRight) step(1); });图片本身要备两套列表用压缩过的缩略图宽 640webp灯箱用大图宽 1600。一开始我偷懒只放了大图手机上相册页要加载十几兆首屏白屏了两秒多非常影响体验。4.5 预约表单字段砍到四个垃圾提交单独处理模板给的预约表单有九个字段包括身份证号、紧急联系人、老人年龄、既往病史等等。这个设计在线上是行不通的——填的人少而且收集敏感信息的风险也高。我砍到了四个称呼、联系电话、想了解的房型下拉、方便联系的时段下拉。备注留一个可选的多行输入。四个字段足够让机构回电剩下的信息电话里问更合适。垃圾提交是绕不过去的问题。这套表单上线两周后开始收到机器提交一开始一天几条后来几十条。我试过三种方案最后用的是蜜罐字段 时间戳校验的组合form idbooking novalidate input typetext namecompany tabindex-1 autocompleteoff aria-hiddentrue classhp-field input typehidden namets idts !-- 其余字段 -- /formdocument.getElementById(ts).value Date.now(); document.getElementById(booking).addEventListener(submit, e { e.preventDefault(); const f e.target; if (f.company.value) return; // 蜜罐被填直接丢弃 if (Date.now() - Number(f.ts.value) 3000) return; // 3 秒内提交判定为机器 // 正常校验与提交 });蜜罐字段用 CSS 移出可视区而不是display: none因为部分自动化脚本会跳过隐藏元素移出视口反而更容易命中.hp-field{ position: absolute; left: -9999px; width: 1px; height: 1px; opacity: 0; }加上这两条之后机器提交基本清零偶尔漏进来的一两条人工也能识别。这里没必要上验证码老人的识别成本太高得不偿失。5. 移动端优先的性能处理这套站点的真实流量分布很集中八成以上来自手机其中相当一部分是中低端机型还有不少是从社交软件里点开的内嵌浏览器。这意味着性能优化不是加分项是及格线。5.1 断点只留三个模板原本有六个断点从 480 到 1440每档都写了独立样式维护起来极其痛苦。我压到了三个768、1024、1280。小于 768 走移动布局768 到 1023 走平板双列1024 以上走桌面。剩下那些细微差别全部用clamp()和min()消化掉。这个做法有个前提布局本身要足够弹性。具体来说卡片区用grid-template-columns: repeat(auto-fit, minmax(280px, 1fr))让列数自动决定而不是在每个断点里手写repeat(3, 1fr)。这样即使设备宽度落在一个不常用的尺寸上布局也不会塌。.card-grid{ display: grid; gap: 20px; grid-template-columns: repeat(auto-fit, minmax(280px, 1fr)); }minmax(280px, 1fr)里的 280 是个需要斟酌的数字。太小会导致手机上字被挤成竖条太大则在平板上只排一列很浪费。这个宽度大致对应一行能放 12 到 14 个汉字配合 18px 的字号刚好。5.2 图片和字体的取舍图片是这类站点最大的体积来源。相册、环境图、房型图加起来几十张原图单张动辄几兆。处理流程是这样原图统一进/img/raw不参与构建用脚本批量输出两档尺寸的 webp同时保留 jpg 兜底。HTML 里用picturesrcsetpicture source typeimage/webp srcset/img/web/room-640.webp 640w, /img/web/room-1280.webp 1280w sizes(max-width: 768px) 100vw, 50vw img src/img/web/room-1280.jpg alt双人间室内实景南向采光 width1280 height853 loadinglazy decodingasync /picturewidth和height一定要写这能提前占位避免图片加载时页面跳动。这个跳动在长页面上尤其致命——用户正读到一半内容突然被推下去很容易误触。首屏那张横幅图不走懒加载反过来要加fetchpriorityhigh并预加载link relpreload asimage href/img/web/hero-1280.webp typeimage/webp字体这块我做了减法。模板引了两款中文字体一款正文一款标题加起来快两兆。中文字体做子集化在内容会变的站点上很麻烦所以我的方案是全站不引中文字体只用在系统字体栈上靠字重和字号建立层次。body{ font-family: -apple-system, PingFang SC, Microsoft YaHei, Source Han Sans SC, Noto Sans CJK SC, sans-serif; }系统字体在各类设备上都做过显示优化在小字号下反而比网页字体更清晰。代价是不同平台的字形略有差异但对这类机构站来说完全可以接受。5.3 首屏实测与优化前后的对比改完之后做了一轮实测用同一台中端手机、同一个网络环境取三次中位数。数据如下指标改版前改版后首屏内容出现3.4 s1.1 s首页总请求数6221首页传输体积4.8 MB620 KB最大内容绘制5.2 s1.9 s布局偏移量0.210.03体积降幅最大的一步是图片换成 webp 并按需加载占了总减少量的八成以上。请求数减少主要靠两件事把零散的图标字体换成内联 SVG把几个小的 JS 文件合并。布局偏移从 0.21 降到 0.03 全靠给图片写死宽高比和给广告位预留高度。经验这类站点不要用我本地打开挺快的来判断。开发机一般性能过剩还得在真机上、用限速网络跑一遍问题立刻现形。6. 上线前后踩过的坑与排查链路前面讲的都是应该怎么做但真正花时间的往往是为什么现在不对。这一节把几个印象深的坑完整记下来包括排查过程因为结论不值钱路径才值钱。6.1 预约表单收不到提交一条完整的排查链路现象是后台一条记录都没有但前端点击提交后提示提交成功。这种看起来成功实际没到的问题最耗时间因为前端没有报错你会本能地怀疑后端。我的排查顺序是这样的从最便宜的一步开始逐层收敛第一步看网络面板。打开开发者工具点提交看有没有请求发出。结果是有请求状态码 200响应体是一段 HTML 而不是 JSON。这一下就把范围缩小了——请求发出去了但地址指错了。第二步对比请求地址。请求打到了/booking.html而不是后端接口。原因是模板里的form没有写action同时提交逻辑里有一段老代码用form.submit()直接触发原生提交。而我的preventDefault写在了另一个监听器里执行顺序在它后面没拦住。第三步确认执行顺序。把两个监听器的注册顺序调过来就好了吗不这治标。正确的做法是把原生提交彻底断掉只走fetchform.addEventListener(submit, async (e) { e.preventDefault(); e.stopImmediatePropagation(); // 切断同一元素上后续监听器 // ...校验 const res await fetch(/api/booking, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify(payload) }); });stopImmediatePropagation()这一行是关键它能阻止同一元素上其他监听器继续执行。如果只是preventDefault()后面那段form.submit()的逻辑照样会跑。第四步验证成功判定。修完地址问题后我又发现代码把HTTP 200直接当成成功而后端返回的是{code: 1, msg: ...}这种信封结构。这意味着接口出错时前端也会提示成功。后来统一改成判断res.ok data.code 0。第五步模拟真实场景。最后一轮用限速网络测发现手机端偶发失败。查下来是提交按钮没有做防重复点击弱网下用户会连点第二、三次请求被后端拒掉并返回错误覆盖了第一次的成功提示。加了按钮禁用和 3 秒节流解决。整个链路走完花了将近一天但每一步的判定依据都很明确没有再走回头路。6.2 手机上出现横向滚动条三个常见源头这个问题在改版过程中反复出现每次的原因都不一样现象常见原因定位方法整页可左右拖动某个元素宽度超出容器给*加outline: 1px solid red逐层扫只有某个区块能拖表格或代码块没套滚动容器找overflow-x缺失的父级拖动后右侧有白边负边距或100vw含滚动条宽度换成100%或calc(100vw - var(--sbw))第三个最常见也最隐蔽。100vw在某些浏览器里包含竖向滚动条的宽度比可视区多出十几像素于是必然出现横向滚动。我的处理是给根元素设overflow-x: hidden治标同时把用到100vw的地方全部换成100%或min(100%, 100vw)。前者是应急后者才是根治。另外提醒一句加overflow-x: hidden到body上在部分移动浏览器里会连带影响吸底条的定位position: fixed会退化成相对 body 定位。所以这个属性最好加在html上或者干脆只做根治不做遮掩。6.3 上线前的那张清单改版收尾时我整理了一份检查项每次交付前过一遍能挡掉大部分低级问题所有hreftel:链接在真机上点一遍确认能唤起拨号表单提交走一遍完整链路包括失败分支和重复提交首页、房型页、相册页在 375px 宽下无横向滚动所有图片有alt装饰图alt页面标题、描述、h1每页唯一且不重复404 页面存在且能回到首页HTTPS 证书有效期确认站点内不混用 http 资源用读屏软件过一遍首页确认朗读顺序合理最后一条很多人会跳过但成本很低收获很大。我就是在那一步才发现吸底条在朗读顺序里排在了页面最前面导致每次打开都在念电话咨询、预约参观把正文全盖过去了。修法很简单给吸底条加aria-hidden之外还需要在 DOM 里把它放到文档末尾靠 CSS 定位到视觉上的底部。7. 把黄色模板复用到第二家机构的做法这套模板后来改给了另外两家机构——一家主色换成了墨绿一家换成了砖红。之所以能在一周内完成靠的不是手快而是前面那些写死变量的规矩。7.1 换色到底要改哪里换主题的实际操作只有一步改tokens.css里的品牌色阶。但前提是组件层没有硬编码颜色。我在交付第一版之前做了一次全项目搜索把pages.css和components.css里所有十六进制色值全部换成了变量引用一共清出七十多处。有一类颜色比较麻烦遮罩和阴影。这些地方用的是rgba()直接换变量不生效。我的处理是把它们也抽成变量:root{ --scrim: rgba(90,62,0,.82); --shadow-soft: 0 2px 10px rgba(90,62,0,.08); }换主题时连这两个一起换整站色调才统一。如果只换了主色遮罩还是褐黄的在墨绿主题下会显得脏。另一类麻烦是内联 SVG 里的颜色。图标如果用了fill#F5B301换主题就不会跟着变。修法是把fill改成currentColor由父元素的color决定svg viewBox0 0 24 24 aria-hiddentrue path d... fillcurrentColor/ /svg这个改动看着琐碎但它让图标能跟着按钮的文字色一起走反而少维护一套逻辑。7.2 交付给非技术人员的编辑说明机构那边通常没有专职前端内容更新靠行政人员。所以我每次交付都会附一份一页纸的说明只讲三件事第一改文字在哪改。指到具体文件和具体行用注释标出来比如!-- 修改这里机构简介第一段 --。第二换图片的规矩。要求宽度不超过 1600格式用 jpg文件名不带中文和空格。第三不能碰的地方。明确告诉他们哪些文件不要动尤其是tokens.css和main.js。这份说明的价值在半年后体现。第一套站上线八个月后机构要改首页一句话行政人员自己五分钟就改完了没找我。而在此之前他们每次改字都要发消息过来来回沟通的成本远超改字本身。还有一个小技巧把首页里最容易被改动的几处机构简介、床位数字、联系方式集中放在 HTML 的同一个区块里并用醒目的注释框起来。这样即使对方不懂代码也能靠注释定位不至于在几百行里翻找。7.3 这套结构还能怎么延展从黄色模板这套结构出发其实不止能用在养老机构。它的核心是高可读性 强行动入口 图片说服这三件事在康复中心、社区日间照料、家政护理这类场景里是通用的改一改文案和图片就能复用。真要延展我会按这个顺序动先把色阶换掉十分钟再调字号如果是面向更年轻的用户可以把根字号从 18 降回 16最后换首页模块的排序比如把服务项目提到首屏之后的位置把环境相册往后挪。三步下来基本就是另一套站点了而代码量几乎不变。我自己的体会是做这类模板项目前期多花半天把颜色和字号抽成变量后面会省下好几天的返工。反过来图快直接改样式表等到第二家、第三家找上门那点省下的时间会连本带利还回去。
