南坪那家老麻抄手的冷柜凌晨一点半还在修，老板顺手把高德地图上的“接单”按钮点成了灰色。可大众点评后台还挂着绿灯，顾客扫码进店，手机却弹出“该门店暂不接受订单”。有顾客拍了张照：店门开着，灯亮着，红油碗里热气直往上窜——配文就一行：“老板在修冰箱，不是在装死。”
三套后台，各自为政
春熙路那家火锅店周五晚八点的数据，我调出来看了三遍。
高德显示42人排队。监控回放里八张桌子空着。美团核销日志里躺着35张未完成的团购券。它们卡在高德接口的队列计数器里，像被遗忘的缓存碎片。
这不是bug。是两套系统对“排队”的定义根本不同。高德认的是POI服务端实时上报的候补队列长度；大众点评的/merchant/status只返回布尔值+人工标注的营业备注字段。中间没桥，只有人蹲在三个Tab之间来回切屏。
成都一位面馆老板跟我说过实话：他把手机壁纸设成高德排队截图，不是为了显摆，是怕自己忘改。结果有天顾客扫完码抬头问：“老板，你壁纸上写‘12人’，怎么门口没人？”他摸出手机一看——壁纸还是上周二下午三点的快照。
静态HTML官网更绝。去年春节加的“年夜饭预订”横幅，至今还挂在首页。没人动它，因为没人记得密码。FTP客户端连上去，最后修改时间戳是2025年1月28日23:59。
填两个ID，等11秒，控制台就动了
yh blog v2.4.1 后台点开「本地生活AI详情页」模块，填大众点评商户号和高德POI ID。没密钥框，不输redirect_uri，也不用翻文档找Webhook签名规则。就像给公众号授权一样，点确认，弹窗消失，状态变成“已同步”。
第一次跑通时，我在控制台看见两条请求并行发出：一条打向大众点评OpenAPI v3.2.0 的 /merchant/status，另一条命中高德 /v4/poi/queue?poi_id=xxx。后者带了 请求头——这是2026年3月起强制的新认证头，旧版SDK直接返回401。
它不干等。高德接口实测均值87.3秒，插件设了92秒超时阈值。超时就先用点评状态兜底，同时后台重试。重试三次失败后，在GEO页顶部加一行小字：“高德数据暂未刷新（最后更新：23:41:07）”。字体比正文小两号，悬停才显示原始响应时间戳和HTTP状态码。
这行字不是免责条款。是它第一次学会说“我不知道”，而不是硬编一个答案。
当两个平台打架，页面只翻译，不判案
大众点评标“营业中”，高德标“暂停接单”。插件不会弹窗让你选。
它按2026年本地生活信源权重模型算分：点评状态可信度0.73（背后是全国327支线下巡检队交叉验证），高德排队延迟容忍值92秒。冲突持续超5分钟，且店内客流传感器波动＞±35%，才触发人工复核流程。
其余时候，它把结论揉成一句带括号的提示：“营业中（高德暂未同步）”。括号里不是装饰，是来源声明。
深圳那家社区药房上个月靠这个逻辑抢回17分钟——高德误将“儿科候诊”标为“暂停服务”，插件比对红外计数上升曲线+状态突变，立刻推消息到企业微信，附两张截图：一张是高德后台错误配置界面，一张是药房监控里家长陆续进门的画面。
这页不是信息展板。它是站在顾客角度，把两套系统吵架的结果翻译成一句能听懂的话。
点“当前排队”，不是跳链接，是掀帘子
页面底部那个按钮，点下去不打开新页，不跳转外链。它唤起高德原生SDK的轻量队列视图。
PWA离线缓存开着——信号断了，上次加载的倒计时和队列结构还在。所有状态变更、人数跳变，都走Webhook推送到企业微信，带原始JSON快照和ISO时间戳。
兰州拉面店老板上周在企业微信里刷到一条推送：排队人数从0跳到17，时间戳是2026-04-12T11:23:44Z，数据来自高德/v4/poi/queue接口。他抬头看了眼店门口——真排上了。没点后台，没调API，就掀开帘子朝后厨喊了声：“面汤再烧两锅！”
同步这个词太重了。实际跑起来，就是几个 HTTP 请求在后台 quietly 拉数据，再把大众点评的营业状态和高德的排队人数塞进模板——没魔法，也没实时推送，就靠每 15 分钟一次的轮询，稳得住。
评论