为什么指向 PDF 的二维码不是数字菜单
在大多数餐厅扫码，得到的是一份 PDF。免费，有人花了十五分钟做出来，技术上也确实能打开。但 PDF 是一张恰好显示在屏幕上的印刷页，数字菜单该做的事它几乎都做不到。下面是诚实的账。
问题一：没人读得下去
菜单是按 A4 或 A3 排版的。手机屏幕宽约 7 厘米。PDF 缩到最小打开，字高三个像素，客人开始双指放大。要读第三栏就得横向滑动，滑丢了位置，再缩小回去找。
这不是小麻烦。这正是你的服务员至今仍被问「这个烩饭里有什么」的原因：客人在 PDF 上放弃了，转回去问人。你加了个二维码，原来的工作量一点没少。
问题二：改动仍然是设计工作
给一道菜涨价，意味着打开源文件、修改、重新导出 PDF、上传回同一个地址、再确认二维码还能打开。如果排版文件在外包设计师手里，那就是一封邮件加一段等待。于是这次涨价被攒到下一次，再下一次，你的菜单挂着三个月的旧价格——正是纸质菜单的老毛病。
问题三：它说不出今晚的情况
鲈鱼在 20:30 卖完了。PDF 无从知晓。客人点了，服务员道歉，客人在压力下重新决定，通常会选更便宜的。托管菜单一键把这道菜隐藏，没有人会经历这个断口。
问题四：过敏原和语言会成倍增加文件
在旅游区你需要三四种语言。那就是三四份 PDF、三四个二维码或一个中间选择页，以及每次改价都要重新导出的三四个文件。再加一列过敏原，每份文件都变宽，手机上的问题更严重。托管菜单只翻译一次，并把过敏原信息绑在菜品上，而不是绑在版式上。
问题五：对谷歌不可见
人们搜索「[你所在城市] 有海鲜饭的餐厅」，谷歌从已索引的文字里作答。藏在二维码后面的 PDF 通常既没有从你的网站链接过去，也无法被有效抓取，所以你的菜名永远不会出现。托管的菜单页就是普通 HTML，和任何页面一样被索引——对许多小店来说，它会成为自己第二受欢迎的页面。
问题六：这是一条死路
PDF 接不了单，无法告诉你 40 个人看了品鉴菜单却无人下单，也没法把任何东西送到后厨。你日后想做的每一项改进，都要从替换它开始。
直接对比
| 二维码 → PDF | 托管数字菜单 | |
|---|---|---|
| 手机阅读 | 放大加拖动 | 为屏幕而做 |
| 改价格 | 编辑、导出、重新上传 | 改一个字段，立刻生效 |
| 售罄菜品 | 做不到 | 一键隐藏 |
| 语言 | 每种语言一个文件 | 自动 |
| 过敏原信息 | 让版式变宽 | 绑在菜品上 |
| 能被谷歌找到 | 实际上不能 | 可以，可索引页面 |
| 照片 | 撑大文件体积 | 按需加载 |
| 能接单 | 不能 | 能 |
| 成本 | 0 欧元 | 9.90 欧元/月起 |
什么时候 PDF 才真的是正确答案
两种情况。第一，本来就打算让客人打印的文件：宴会方案、团体套餐、外烩价目表。那是文档，而 PDF 正是文档的正确格式。第二，菜单从不变、也没打算变的店：两个月旺季、只有六个品项的海滩酒吧不需要系统。
不重新录入就离开 PDF
- 给纸质菜单拍张照，或者直接上传那份 PDF。
- IQ Rest 读取后生成分类、菜品和价格——大约五分钟，而不是一整晚。
- 核对价格，修正识别读错的地方。
- 把现有二维码指向新菜单，或按桌重新打印。
常见问题
可以免费给 PDF 菜单做二维码吗？
可以，大约十五分钟。请使用指向你自己域名网址的静态码，这样以后替换文件时不必重印。
谷歌会索引 PDF 菜单吗？
谷歌总体上能索引 PDF 文件，但只能通过印刷二维码访问的菜单 PDF 通常没有任何链接指向它，所以实际上不会在菜品或菜系搜索中出现。
那我把 PDF 直接做成手机竖版呢？
对可读性有帮助，值得做。但它解决不了更新、售罄、语言、过敏原和点单——阅读问题只是六个问题里的第一个。
换成托管菜单后能保留我的设计吗？
颜色、logo 和菜名都会保留。页面版式不会，因为它要按手机屏幕重新构建——而这正是更换的意义所在。
我需要重印二维码吗？
如果现在的码指向你能控制的网址，就不需要：把那个网址重定向到新菜单即可。如果它指向某个生成器的域名或云端硬盘链接，就得换新码。