去年我们工作室接了个急单——帮一家连锁照相馆做证件照价格表，客户要求3天内上线。我第一反应是写个静态HTML页面，结果老板看了一眼说：“以后每开一家分店都要改代码，你受得了？”这句话把我问住了。后来我才明白，制作证件价格表这件事，表面是排版问题，底层其实是数据与展示的耦合方式问题。
说白了，你选择哪种技术路线，决定了三个月后你是轻松改个数字，还是对着代码骂娘。今天我用两个真实方案拆开讲，从底层原理聊到实操坑点，看完你大概能省下至少两次返工。
方案A：静态硬编码——快是真的快，痛也是真的痛
先说我最初的做法。打开编辑器，一个<table>标签包住所有价格行，尺寸、底色、张数、价格全部写死在HTML里。半小时搞定，上传服务器，完事。
这种方式的底层逻辑特别简单：浏览器解析HTML，渲染出表格，没有中间层。好处是加载速度极快——我们实测过，一个纯静态的证件照价目表页面，首屏渲染时间在80毫秒以内，比任何动态方案都快。对于只有一两家店、价格半年不改一次的小影楼，这方案够用。
但问题出在“变”字上。客户第二个月加了“签证照加急”品类，第三个月调了“立等可取”的加价幅度。每次改动我都要手动找到对应行，改数字、调样式、重新上传。更麻烦的是，分店价格不一样——城东店比城西店贵5块，静态页面就得复制两份HTML。坦白讲，到第五次改价的时候，我已经在考虑转行了。
还有一个隐蔽的坑：静态表格对移动端不友好。证件照价格表通常有6到8列，手机上横向滚动体验极差。你要么写媒体查询重新布局，要么让用户歪着脖子看——哪种都不体面。
方案B：数据驱动渲染——前期多花两小时，后期省下两天
后来我换了个思路。把价格数据抽出来，存成JSON文件，页面用JavaScript动态渲染表格。结构大概长这样：一个包含“尺寸名称、规格毫米数、背景色选项、单张价格、加急费用”的对象数组，循环生成行。
底层原理上，这相当于把数据层和展示层解耦。价格变了？改JSON里一个数字，所有引用该数据的页面同步更新。分店差异？加个branch字段，渲染时按参数过滤。我们在证件照尺寸规范那篇文章里整理过常用规格数据，直接复用就行，不用重新录入。
这方案还有个意外收获：渲染逻辑可以复用到小程序和公众号菜单里。同一份JSON，网页端用fetch拉取，小程序用wx.request，一套数据三端展示。去年双十一前客户临时要加“全家福证件照套餐”，我只改了JSON里一个对象，三个终端同时生效——那一刻我觉得前期的两小时没白花。
当然代价也有。首屏需要等JS执行，实测比静态方案慢120毫秒左右。如果JSON文件没做好缓存，每次访问都请求一次，服务器压力会上去。我的做法是给JSON加版本号查询参数，配合CDN缓存，基本抹平了这点延迟。
两种方案怎么选？看三个硬指标
别急着站队，先回答三个问题。
第一，你的价格变不变？半年内调价超过两次，或者有分店差异化定价，直接上方案B。静态方案每次改动的隐性成本——找代码、改错行、重新部署——加起来远超你想象。我统计过自己前五次改价，平均每次耗时25分钟，而搭好动态渲染框架只用了不到两小时。
第二，团队里有没有人能维护JS？方案B需要有人看得懂数组遍历和条件渲染。如果你们店连个会用Excel公式的人都难找，那老老实实静态页面，至少不会因为一个语法错误导致整张表白屏。说实话，技术选型最怕“方案很先进，但没人会修”。
第三，要不要多端同步？只做PC官网，静态够用。但凡涉及手机端、小程序、甚至店内电子屏，数据驱动是唯一不让自己发疯的选择。我们给那家连锁照相馆最终落地的就是方案B——他们后来在证件照拍摄流程页面里也嵌了同一份价格数据，客户选完尺寸直接看到报价，转化率提了18%。
一个折中做法，以及我的最终建议
如果你既想要静态的速度，又想要动态的灵活，可以试试“构建时渲染”：用Node脚本读取JSON，生成静态HTML文件再上传。用户拿到的是纯静态页面，你维护的却是数据源。这方案在11ty或Astro这类工具里几乎是默认能力，学习曲线比想象中平缓——我带着一个只会HTML的实习生半天就搭起来了。
但我不推荐所有人都走这条路。工具链多了，调试链路就长，出问题时排查成本翻倍。小团队、低频改动、单端展示——这三个条件满足两个以上，静态硬编码依然是性价比最高的选择。制作证件价格表这件事，核心不是炫技，是让改价格的人不骂娘、看价格的人不迷糊。
回到开头那个急单。我们最终交付的是一份JSON数据加一个渲染模板，客户运营自己在后台改数字，再也没找过我。上周他们开了第四家分店，据说只花了十分钟配置新价格——你看，底层原理选对了，后面全是顺水推舟的事。如果你也在纠结证件类价目表的技术方案，不妨从“谁会来改这张表”倒推，答案通常比想象中清晰。