企业官网建设流程全解析

简介：面向公众号H5扫码点餐场景，这套运营版源码包基于云好客4.7.0版本打造，覆盖桌台扫码、菜单展示、下单支付等核心环节，适合餐饮行业开发者、小程序服务商及希望快速搭建点餐系统的技术入门者使用。资源共478个文件，压缩包约2.53MB，代码组织清晰，包含75个PHP后端逻辑文件、74个JS交互脚本、58个HTML页面模板、30个CSS样式文件，以及130个GIF动图和87个PNG图片资源，覆盖界面展示、动效反馈与样式设计，另含少量字体、图标、样式映射等辅助文件，便于完整还原项目运行环境。已有839人学习下载，通过源码可学习H5点餐系统的整体目录结构、前后端数据交互方式、常用UI组件与页面布局技巧，还可获得一套可直接运行的运营版资源，便于对照练习或快速商用改造，实用价值较高。

1. 扫码点餐H5并没有想象中那么多页面

拿到云好客扫码点餐4.7.0运营版这套公众号源码，第一眼容易被前端目录里十几个CSS文件吓到：H-ui.css、H-ui.min.css、aui.css、iconfont.css、wangEditor.css、layer.css、uploader.css、list.css……它们并不是堆在同一页上的样式，而是同一套系统内部三种角色的分界：顾客用手机打开的H5菜单、商家登录后的PC管理后台、以及后厨打印端的样式依赖。4.7.0这个版本在运营层加了会员卡、优惠券和打印模板，所以静态资源比普通开源点餐包厚不少。适合正在接餐饮SaaS项目、需要快速搭微信生态点餐系统的团队参考，也适合想接管完整公众号扫码点餐源码做二次开发的人。

2. 前端资源拆解：顾客端H5样式、后台样式与编辑器依赖

2.1 顾客点餐端以 aui.css 为骨架，H-ui.css 是后台专属

先明确一个容易误判的点：H-ui.css 和 H-ui.min.css 是同一份样式的普通版与压缩版，但顾客扫码打开的 H5 点餐页并不会整页使用它。H-ui 本身是面向后台管理界面的框架，自带栅格、表格、按钮、弹层这一套，在点餐系统里它服务的是商家登录后的店铺管理、菜品管理、订单列表页面。真正给手机端扫码点餐撑门面的是 aui.css，它把底部标签栏、列表、表单开关、抽屉这类移动端组件压缩得比较小，适合在微信内置浏览器里快速渲染出点餐列表。

资源包里同时出现 aui.css 和 iconfont.css 是常见组合：aui 管布局，iconfont 管菜单分类图标、加减号、购物车这类小图形。注意 iconfont.min.css 与 iconfont.css 内容一致，上线时用 min 版本即可，开发环境用未压缩版本方便改字号和颜色。

2.2 编辑器依赖：wangEditor 出现在商家维护商品描述、公告和打印小票模板

wangEditor.css 和 wangEditor.min.css 同样是一组压缩与否的差别，它对应商家后台的富文本编辑器。在这个点餐场景里，编辑器的用途多半是三处：商品详情带图文的说明、店铺公告的排版、以及打印小票模板里对“菜品名、数量、备注、桌号”这类变量的排版。经营者不用写代码，直接拖拽变量和文字就能改小票格式，运营版的值钱点之一在这。

layer.css 和 layer.js 是异步加载弹窗资源，点餐页确认加购、后台批量上下架、下单异常提醒都会调它。uploader.css 则出现在菜品图片上传、店铺头像上传的页面里，它依赖对应的 uploader.js 做图片预览与压缩上传，建议在后台限制 2MB 以内的 JPG/PNG，避免微信内置浏览器上传大图后白屏。

2.3 页面骨架示例：点餐入口的静态资源引用

扫码点餐的完整链路是：顾客扫桌码进入到带 token 参数的 URL，公众号内授权拿到 openid，然后进入点餐首页。打开源码包里的点餐入口文件，头部的静态资源引用大致如下：

<link rel="stylesheet" href="/static/h5/css/aui.css" /> <link rel="stylesheet" href="/static/h5/css/iconfont.css" /> <link rel="stylesheet" href="/static/h5/css/list.css" /> <script src="/static/h5/js/aui.js"></script> <script src="/static/h5/js/vue.min.js"></script>

提示：顾客端页面尽量不要引入 wangEditor.css 和 H-ui.css。这两个文件加起来超过 200KB，对移动端首屏有实际影响。如果要在顾客端做富文本展示，用 v-html 渲染后台存好的 HTML 即可，不需要把编辑器脚本带到前台。

这里的 vue.min.js 是常见点餐源码的实际依赖，4.7.0 运营版顾客端一般用 Vue 做数据绑定，aui.js 负责交互组件，两者并不冲突。

2.4 静态资源分工速查表

这张表能帮助新接手的人快速判断：出了问题先看引用的是移动端组件还是后台组件，再决定排查方向。

3. 点餐主流程实现：菜单渲染、购物车与订单提交的H5交互

3.1 菜单数据模型与分类切换

点餐页核心是菜品列表和分类。常见做法是后端一次性返回全部菜品和分类，前端用选项卡切换分类。数据结构通常是：

{ "code": 0, "data": { "shop_name": "示例餐厅", "categories": [ { "id": 1, "name": "热销", "goods": [ { "id": 101, "name": "招牌卤肉饭", "price": 1800, "stock": 50, "sold": 320 } ] } ] } }

我一般建议把价格字段按“分”为单位传整数，前端再除以 100 展示。原因是微信支付金额、购物车计算和优惠券抵扣统一用分做单位，可以避免 JavaScript 浮点误差。核对 4.7.0 后台的“价格单位”设置，如果后台默认不是分，前端需要加转换层。

分类切换不要每次重新请求接口，接口数据里一次性包含全部分类，前端只做本地过滤，这样扫码后弱网环境下体验更好。切换分类时还要处理“已售罄”和“估清”状态，后端返回的 stock 为 0 时灰色置灰，这个判断需要同时作用于购物车入口，否则会出现顾客把已售罄菜加到购物车后无法结算的尴尬情况。

3.2 购物车状态管理：localStorage 兜底

点餐页购物车数据量不大，用 Vue 实例里的全局数据保存后，再用 localStorage 做持久化。

const CART_KEY = 'yunhaoke_cart_' + shopId; function addToCart(goods, count) { let cart = JSON.parse(localStorage.getItem(CART_KEY) || '[]'); const found = cart.find(item => item.id === goods.id); if (found) { found.count += count; } else { cart.push({ id: goods.id, name: goods.name, price: goods.price, count: count, sku: goods.sku || '' }); } localStorage.setItem(CART_KEY, JSON.stringify(cart)); renderBadge(); }

这段代码有两点要说明：购物车 key 必须带 shopId，否则顾客扫两家店的码会互相污染购物车数据；菜品价格或库存发生变化后，购物车里的旧数据要在下单前重新校验，而不是直接信任本地缓存。比较稳妥的策略是在提交订单前用一个比对接口，把购物车里每个菜品的当前价格和库存重新拉一遍，价格变动就用新价格重新结算，并在前端弹窗提示。

3.3 提交订单与调起微信支付

提交订单需要三个参数：桌台标识（table_id）、购物车商品 JSON、顾客 openid。openid 来自微信授权，前端拿不到的情况下由后端通过 session 透出，前端只负责在 URL 或 JS 全局变量里取：

const params = { table_id: getQuery('table_id'), items: JSON.stringify(cart), openid: window.__OPENID__, remark: remarkText.value }; axios.post('/api/order/create', params).then(res => { if (res.data.code === 0) { WeixinJSBridge.invoke('getBrandWCPayRequest', res.data.pay_params, function(resp) { if (resp.err_msg === 'get_brand_wcpay_request:ok') { window.location.href = '/h5/order-detail?id=' + res.data.order_id; } }); } else { layer.msg(res.data.msg || '下单失败，请重试'); } });

pay_params 由后端统一下单接口返回，包含 appId、timeStamp、nonceStr、package、signType、paySign 这六个字段，前端不能自己拼签名。真正容易踩坑的环节是回调地址：统一下单时设置的 notify_url 必须是公网 HTTPS 地址，且路径需要与公众号后台的“支付授权目录”在同一目录层级，否则支付成功后订单状态无法回调更新。

4. 运营版功能落地：店铺装修、打印机配置与会员营销

4.1 店铺装修：后台如何修改点餐页的轮播与公告

运营版的核心是给商家自己动手改界面。店铺装修界面通常把首页拆成店铺信息、轮播图、公告、分类图标四块，商家保存后，顾客端通过接口拉取最新配置。有一个常见问题：商家在后台改了轮播图，顾客端一直不更新，排查后往往是 CDN 缓存或浏览器缓存。建议在商家后台“预览 H5”入口生成带版本号参数的地址，例如/h5/index?shop_id=12&v=20250115，这样每次修改都能强制刷新。

轮播图的裁剪比例也要提前约定好，建议统一为 750x360 像素，这是微信内置浏览器最常见到的列表首图宽高比。图片过大或比例不统一会让 aui.css 里写死的样式变形。

4.2 后厨打印机配置的常见接法

云好客扫码点餐4.7.0运营版对打印机的支持，常见接法是云打印机方案，下单成功后由服务端把订单推送至打印机队列，而不是用浏览器直接打印。配置打印机时，需要看四个参数：打印机编号、终端号、密钥、以及关联的菜品分类。

这里有一个运营场景容易忽略：需要把后厨打印机和吧台打印机分开。热菜订单推到后厨，饮料甜品推到吧台，避免一张单子打两遍。这个逻辑在后台“打印设置”里通常用菜品分类绑定打印机实现。改配置后，不要直接在后台点“打印测试”，因为部分云打印接口测试页走的是另一条通道，不能代表真实下单链路的模板渲染结果。

4.3 会员与营销规则：优惠券、满减与余额的边界

运营版通常带会员余额和优惠券。顾客在点餐页看到“余额支付”选项，下单时优先扣余额，余额不足再调起微信支付。优惠券要明确两个边界：优惠券使用门槛是否计算打包费、满减和会员折扣是否叠加。这些规则在后台配置里经常混在一起，开发时最好在订单结算结构体里把优惠明细单独输出，方便核对。

// 服务端优惠计算示例 function calcDiscount($orderAmount, $coupon, $memberLevel) { $amount = $orderAmount; if ($coupon['type'] === 'cash') { $amount = max(0, $amount - $coupon['value']); } elseif ($coupon['type'] === 'discount') { $amount = $amount * $coupon['value'] / 10; } if ($memberLevel > 2) { $amount = $amount * 0.95; // 会员折扣 } return round($amount, 2); }

注意这个示例中会员折扣直接叠加在优惠券之上，如果后台配置的规则是“不与优惠券同享”，需要加一个互斥判断，并把互斥结果写入订单日志，否则后续对账时商家会质疑金额来源。运营版源码里的“会员卡”模块还包含储值赠送，赠送金额不计入可退款余额，这个字段在数据库里必须单独列出来，不能用同一个 balance 字段。

5. 微信公众号H5调试与部署的四个关键细节

5.1 微信授权路径与 session 串联

微信网页授权回调地址是公众号后台配置死的一个域名路径，回调后 session 里保存 openid，点餐页的所有接口都需要校验这个 session。本地调试时最容易遇到的问题：代码里用了http://localhost去静默授权，公众号后台不认这个域名，于是 openid 一直为空。常见做法是本地通过 hosts 把线上域名指到 127.0.0.1，再用微信开发者工具打开，并在开发者工具里设置 cookie 不校验，这样才能拿到完整 session。

5.2 JSSDK 签名失败：URL 不一致是头号原因

如果点餐页需要调 JSSDK 做自定义分享或隐藏菜单，签名校验是最常见的问题。签名用的 URL 必须和当前页面地址完全一致，包括末尾不带/、包括所有 query 参数。

# 后台日志里常看到两种地址 https://api.xxx.com/h5/index # 签名成功 https://api.xxx.com/h5/index? # 多一个问号，签名失败

排查时先把当前页面地址复制出来，去掉 hash 部分再签名，微信官方规则是只取location.href.split('#')[0]。另外，签名算法里timestamp和nonceStr每次都要重新生成，不能把第一次签好的结果缓存复用。

5.3 Nginx 静态资源缓存策略

顾客端入口 HTML 不能缓存，否则商家改完菜价顾客端不更新，但 CSS、JS、图片可以长缓存，减少微信内重复加载的成本。

location /h5/ { add_header Cache-Control "no-cache"; } location /static/ { expires 7d; add_header Cache-Control "public"; }

这里no-cache的意思是每次都回源验证，而不是不缓存，验证通过仍可使用本地副本，适合入口页；expires 7d配合文件名加 hash 更稳妥，因为如果 CSS 文件名不变，7 天内改了内容顾客端仍会拿旧文件。运维规范一点的团队会让前端构建时给 CSS、JS 自动加版本号，list.css?v=20250115，避免长缓存带来的更新滞后。

5.4 用开发者工具验证完整点餐链路

最后一个技巧：在微信开发者工具里，把调试模式打开，扫码进入点餐页后，手动模拟从加购到支付的完整链路。支付环节不能真的付钱，可以用测试商户号或者直接在后端把支付环节跳过，只验证订单创建、打印推送、库存扣减。验证完成后，把开发者工具的清缓存功能打开，重新扫码确认入口页没有引用到旧版 aui.css 或 list.css，这一步能过滤掉大多数本地看正常、线上样式错乱的发布事故。

本文还有配套的精品资源，点击获取