简介：这是一套面向实体商家与本地生活服务商的NFC碰一碰营销系统源码，支持贴牌部署，帮助餐饮、零售、美业、健身、景区、酒店等场景快速搭建碰碰卡与爆店码工具。核心能力包括一键发布抖音、小红书笔记与视频、快手、视频号，以及一键完成大众点评、美团、抖音、高德、百度打卡收藏，覆盖店外引流、店内互动、展会促销与会员沉淀等运营环节。资源包共1037个文件，以707个php后端文件为主，配合60个html、24个js、24个json及22个wxss、22个wxml小程序页面文件，另有png、jpg等图片素材与config、functions配置脚本，压缩包约6.32MB，结构完整便于二次开发与贴牌。目前已有495人学习下载，适合需要快速落地碰一碰营销系统的开发者、服务商与商家运营人员参考部署。
1. 碰碰卡 NFC 碰一碰：从一张贴纸到多平台内容分发的完整方案
商家前台贴一张卡片，顾客手机碰一下，抖音、小红书、快手、视频号的内容发布页依次弹出，大众点评、美团、高德、百度的打卡入口自动跳转——这套「碰碰卡」方案要解决的核心问题只有一个：把顾客的一次到店行为，转化成多个平台上的内容资产和评价数据。适合谁用？做本地生活服务的商家运营方、想给商户做数字化赋能的系统集成商，以及需要一套可贴牌、可私有化部署源码的技术团队。它不是简单的 NFC 标签写入工具，而是一套「碰一碰爆店码」的完整分发系统，涉及标签写入、链接路由、平台跳转协议适配、多商户管理和贴牌部署几个关键环节。下面按需求、设计、实现、验收的顺序，把整套方案拆开讲清楚。
2. 需求拆解与技术选型：为什么是 NFC 而不是二维码
2.1 商家侧的真实痛点
先看商家每天面对的场景。一家餐饮店或美业门店，想让顾客帮忙发一条抖音探店视频、写一条大众点评评价，传统做法是贴二维码、放台卡、服务员口头引导。二维码的问题在于：顾客要打开相机、对准、识别、等待跳转，中间任何一步卡住就流失了。而且二维码容易被替换、被遮挡，商家无法控制内容。
NFC 碰一碰把交互压缩到「手机贴近卡片」这一个动作。主流手机（iOS 14 以上、Android 开启 NFC 的机型）碰一下即可唤起预设的 URL Scheme 或 Universal Link，直接跳到目标 App 的指定页面。这个体验差异直接决定了转化率——从「三步操作」变成「一步触碰」，是这套方案成立的前提。
需求可以归纳成四条：一是多平台覆盖，抖音、小红书、快手、视频号的内容发布，以及大众点评、美团、抖音、高德、百度的打卡收藏；二是多商户管理，一套系统要能服务成百上千个商家，每个商家有独立的卡片和跳转配置；三是可贴牌，运营方要能换成自己的品牌对外交付；四是可私有化部署，源码掌握在自己手里，数据不经过第三方。
2.2 技术选型：NFC 标签 + 云端路由 + 平台协议适配
选型上分三层。硬件层用 NTAG213/215/216 系列的 NFC 标签，成本低、容量够写一条 URL，兼容性覆盖绝大多数手机。为什么不直接把目标平台的链接写进标签？因为平台链接会变、商家配置会改，写死了就没法运营。所以中间加一层云端路由：标签里只写一个短链，指向自己的服务器，服务器根据卡片 ID 查出当前商家的配置，再返回对应的跳转逻辑。
云端路由层用常见的 Web 后端即可，Node.js 或 Java 都能做，核心是一张卡片-商户-配置的映射表和一个跳转分发接口。平台协议适配层是最麻烦的部分，因为每个 App 的唤起方式不同：抖音用snssdk1128://开头的 scheme，小红书用xhsdiscover://，快手、视频号各有各的规则，大众点评、美团、高德、百度也都有各自的 scheme 或 Universal Link。这一层要做的是把「发布笔记」「发布视频」「打卡」「收藏」这些业务动作，翻译成对应平台的跳转地址。
提示：平台 scheme 属于各 App 的私有协议，会随版本变化，方案里必须把这一层做成可配置的，而不是硬编码在代码里。
2.3 贴牌与部署形态
贴牌能力体现在两个地方：一是前端展示层（管理后台的 Logo、名称、域名），二是卡片本身的印刷和写入内容。源码部署意味着运营方拿到代码后，改配置、换品牌、部署到自己的服务器，就能对外交付。部署形态通常是「一台服务器 + 一个数据库 + 一套管理后台」，商家通过后台生成卡片、配置跳转目标，运营方通过后台管理所有商户。
3. 总体架构设计：三层结构与四个核心模块
3.1 三层架构的职责划分
整套系统按「接入层—业务层—数据层」三层来组织。接入层负责接收 NFC 标签触发的跳转请求，做卡片识别和参数解析；业务层负责根据卡片 ID 查询商户配置、组装跳转逻辑、记录触碰事件；数据层存储商户信息、卡片信息、跳转配置和统计数据。
这样分层的好处是，卡片本身不承载业务逻辑，只是一把「钥匙」。钥匙丢了可以挂失重发，配置改了不用重新写卡，运营方在后台改一下，所有已发出的卡片立即生效。这是整套方案能规模化运营的关键。
3.2 四个核心模块
第一个是卡片管理模块，负责卡片的生成、绑定、挂失和状态管理。每张卡片有唯一 ID，绑定到一个商户，可以配置多个跳转目标。
第二个是跳转配置模块，这是业务核心。一个商户可以配置「碰一下默认跳抖音发布页」，也可以配置「碰一下弹出选择菜单，让顾客选发抖音还是写点评」。配置的粒度决定了运营的灵活度。
第三个是平台适配模块，把业务动作翻译成各平台的跳转地址。这一层用配置表驱动，新增平台只需加一条配置，不改代码。
第四个是数据统计模块，记录每次触碰的时间、卡片、跳转目标、是否成功唤起，为商家提供「碰了多少次、跳转了多少次、转化了多少」的数据。
3.3 数据表设计
核心表结构如下，用 SQL 表示：
-- 商户表：一个商户对应一个商家 CREATE TABLE merchant ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(64) NOT NULL COMMENT '商户名称', brand_id BIGINT COMMENT '所属贴牌品牌', status TINYINT DEFAULT 1 COMMENT '1正常 0停用', created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 卡片表：一张物理卡片 CREATE TABLE card ( id BIGINT PRIMARY KEY AUTO_INCREMENT, card_uid VARCHAR(32) UNIQUE NOT NULL COMMENT '卡片唯一标识，写入NFC标签', merchant_id BIGINT NOT NULL COMMENT '绑定商户', status TINYINT DEFAULT 1 COMMENT '1正常 2挂失', created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 跳转配置表：一个商户可配多条 CREATE TABLE jump_config ( id BIGINT PRIMARY KEY AUTO_INCREMENT, merchant_id BIGINT NOT NULL, action_type VARCHAR(32) NOT NULL COMMENT 'publish_note/publish_video/checkin/collect', platform VARCHAR(32) NOT NULL COMMENT 'douyin/xiaohongshu/kuaishou/shipinhao/dianping/meituan/gaode/baidu', target_url VARCHAR(512) NOT NULL COMMENT '组装好的跳转地址', sort_order INT DEFAULT 0 COMMENT '菜单排序', status TINYINT DEFAULT 1 ); -- 触碰记录表：统计用 CREATE TABLE touch_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, card_uid VARCHAR(32) NOT NULL, merchant_id BIGINT NOT NULL, platform VARCHAR(32), action_type VARCHAR(32), user_agent VARCHAR(256), created_at DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_card (card_uid), INDEX idx_merchant_time (merchant_id, created_at) );card_uid是写入 NFC 标签的唯一字符串，通常用短链形式，比如https://your-domain.com/c/ABC123。标签里只存这个短链，服务器收到请求后用ABC123反查卡片和商户。jump_config表把「平台 + 动作」映射到具体 URL，新增平台或调整跳转规则只改数据不改代码。touch_log表支撑后续的数据看板，商家能看到每张卡片被碰了多少次。
4. 核心模块实现：跳转分发与平台适配
4.1 跳转分发接口的实现
顾客碰卡后，手机浏览器打开短链，服务器需要判断：是直接跳转，还是先展示一个选择页。如果商户只配了一个目标，直接 302 跳转；如果配了多个，返回一个轻量 H5 页面让顾客选。
// 跳转分发接口（Node.js + Express 示例） app.get('/c/:cardUid', async (req, res) => { const { cardUid } = req.params; const ua = req.headers['user-agent'] || ''; // 1. 查卡片和商户 const card = await db.query( 'SELECT c.merchant_id, c.status, m.status AS m_status FROM card c ' + 'JOIN merchant m ON c.merchant_id = m.id WHERE c.card_uid = ?', [cardUid] ); if (!card || card.status !== 1 || card.m_status !== 1) { return res.status(404).send('卡片无效或已停用'); } // 2. 查该商户的跳转配置 const configs = await db.query( 'SELECT * FROM jump_config WHERE merchant_id = ? AND status = 1 ORDER BY sort_order', [card.merchant_id] ); // 3. 记录触碰事件（异步，不阻塞跳转） db.query( 'INSERT INTO touch_log (card_uid, merchant_id, user_agent) VALUES (?, ?, ?)', [cardUid, card.merchant_id, ua] ).catch(() => {}); // 4. 单目标直接跳，多目标返回选择页 if (configs.length === 1) { return res.redirect(302, configs[0].target_url); } return res.render('select', { configs, cardUid }); });这段代码的关键点有三个。第一，卡片和商户的状态都要校验，任何一方停用都不能跳转，这是运营方控制风险的手段。第二，触碰记录用异步写入，不能因为写日志失败影响顾客跳转体验。第三，单目标和多目标走不同分支，单目标直接 302 减少一次页面加载，多目标才渲染选择页。
4.2 平台跳转地址的组装
平台适配的核心是把业务动作翻译成 URL。以抖音发布视频为例，scheme 形式大致是snssdk1128://加上具体的路径参数；小红书发布笔记用xhsdiscover://系列。这些地址不能硬编码，要放在配置里，由后台维护。
// 平台适配：根据平台和动作组装跳转地址 const platformScheme = { douyin: { publish_video: 'snssdk1128://openplatform/share?type=video', publish_note: 'snssdk1128://openplatform/share?type=note', checkin: 'snssdk1128://poi/detail?poi_id={poiId}' }, xiaohongshu: { publish_note: 'xhsdiscover://post?type=note', publish_video: 'xhsdiscover://post?type=video' }, dianping: { checkin: 'dianping://shopinfo?id={shopId}', collect: 'dianping://shopinfo?id={shopId}&action=collect' } // 快手、视频号、美团、高德、百度同理，按平台文档补充 }; // 组装：把商户配置的 poiId/shopId 填进模板 function buildTargetUrl(platform, action, params) { const tpl = platformScheme[platform]?.[action]; if (!tpl) throw new Error('未支持的平台动作'); return tpl.replace(/\{(\w+)\}/g, (_, k) => params[k] || ''); }这里用模板占位符的方式，把商户的poiId、shopId等参数填进去。每个商户在不同平台的门店 ID 不同，这些 ID 在商户入驻时录入后台。新增一个平台，只需在platformScheme里加一组配置，再在后台的跳转配置里引用，不用改分发逻辑。
注意：部分平台的 scheme 在浏览器中直接跳转会被拦截，通常的做法是先用一个中间页做「唤起检测」，唤起失败则引导用户手动打开 App。这个中间页的兼容处理是整套方案里最容易翻车的地方，后面单独讲。
4.3 多商户与贴牌配置
贴牌能力通过品牌表和管理后台的配置实现。品牌表记录品牌名称、Logo、域名、主题色，管理后台根据当前登录账号的品牌渲染界面。卡片印刷时，运营方用自己的品牌模板批量生成二维码或卡面设计，写入的短链指向自己部署的服务器域名。
多商户隔离靠merchant.brand_id关联品牌，运营方登录后只能看到自己品牌下的商户。数据统计也按品牌维度聚合，方便运营方给商家出月度报告。
5. 避坑与常见问题排查
5.1 碰卡没反应，手机识别不到
现象是顾客手机贴近卡片，没有任何弹窗或提示。原因通常有三个：一是手机 NFC 开关没开，部分安卓机默认关闭；二是卡片类型不兼容，低频卡或非 NDEF 格式的卡无法被手机读取；三是卡片写入格式不对，没有按 NDEF 标准写入 URL 记录。解决方式是统一采购 NTAG 系列标签，写入时用标准 NDEF URI 记录格式，并在卡片旁印一句「请开启 NFC 后碰触」的提示。
5.2 跳转被浏览器拦截，唤起 App 失败
现象是短链打开后，页面提示「无法打开链接」或停在中间页不动。原因是各平台 scheme 在部分浏览器（尤其是内置浏览器）里被限制，必须由用户手势触发或走 Universal Link。解决方式是做唤起检测：页面加载后尝试跳转，用定时器判断是否成功切到后台，若 2 秒内没切走，则展示「点击打开 App」的按钮，让用户手动触发。这个兜底逻辑是必须的，不能省。
5.3 平台 scheme 失效，跳转到了错误页面
现象是原本能跳的链接某天突然跳到 App 首页或报错。原因是平台更新了私有协议，旧 scheme 被废弃。解决方式是把 scheme 配置化，运营方在后台能改；同时建立监控，统计各平台的跳转成功率，某个平台成功率骤降就说明协议可能变了，及时更新配置。
5.4 多商户数据串了，A 商家看到 B 商家的数据
现象是后台查询时出现不属于当前商户的记录。原因是查询条件漏了merchant_id或brand_id过滤，或者卡片绑定时写错了商户 ID。解决方式是在数据访问层强制带上商户维度过滤，所有查询接口的入参必须包含当前登录账号的商户或品牌 ID，并在测试阶段用两个商户的数据交叉验证。
5.5 触碰统计不准，数据对不上
现象是商家反馈实际碰卡次数和后台统计差很多。原因是触碰记录只在短链被打开时写入，如果顾客碰卡后直接跳转、页面没完全加载，或者用了缓存，记录可能丢失。解决方式是把记录写入放在跳转之前同步执行（或写入消息队列保证不丢），并对同一卡片短时间内的重复触碰做去重，避免刷量。
6. 验收与答辩：怎么证明这套方案真的能跑
验收这套方案，不能只看代码能不能编译，要按「硬件—跳转—平台—数据」四条线走一遍。
硬件线：准备三台不同品牌的手机（至少一台 iOS、一台安卓），用标准 NFC 写入工具把短链写进卡片，确认三台手机碰卡都能弹出浏览器并打开短链。这一步验证的是标签兼容性和写入格式。
跳转线：在后台配置单目标和多目标两种商户，分别碰卡，确认单目标直接跳转、多目标弹出选择页，且选择后能正确唤起对应 App。这一步验证的是分发逻辑和平台适配。
平台线：逐个平台验证。抖音、小红书、快手、视频号各测一次发布动作，大众点评、美团、抖音、高德、百度各测一次打卡或收藏动作。记录每个平台的成功率和失败时的表现，失败的按第 5 章的排查方法定位。这一步是答辩时最能体现工作量的部分，建议做成一张表格：
| 平台 | 动作 | 唤起方式 | 成功率 | 失败表现 | 兜底方案 |
|---|---|---|---|---|---|
| 抖音 | 发布视频 | scheme | 待测 | 停在中间页 | 手动按钮 |
| 小红书 | 发布笔记 | scheme | 待测 | 无响应 | 手动按钮 |
| 大众点评 | 打卡 | scheme | 待测 | 跳首页 | 引导搜索 |
| 美团 | 收藏 | scheme | 待测 | 无响应 | 手动按钮 |
数据线：碰卡若干次后，查touch_log表，确认记录数、卡片 ID、商户 ID、时间都对得上；再在后台看统计看板，确认聚合数据与明细一致。这一步验证的是数据链路完整性。
答辩时，评委最可能问的三个问题是：平台 scheme 失效了怎么办（答：配置化 + 监控）、多商户数据怎么隔离（答：查询强制带商户维度）、贴牌怎么实现（答：品牌表 + 后台配置渲染）。把这三个问题的答案准备好，基本就稳了。
我自己的习惯是，每次交付这类多平台跳转方案前，一定拿三台真机把每个平台的跳转走一遍，把失败的表现截图存档。因为平台协议这东西，文档写的和实际跑出来的经常对不上，只有真机验证过的才算数。希望这套结构能帮到你，需要完整源码和部署文档的，可以按项目里的方式获取。
本文还有配套的精品资源，点击获取
