我们踩过的坑,和怎么爬出来的

2026-08-14 · 1 分钟

我们踩过的坑,和怎么爬出来的

做独立产品最迷人的地方,是你得一个人把「造产品的人、运维的人、被搜索引擎骂的人」全当一遍。

这一路我们摔了不少跟头。摔得越狠,爬起来记住的东西越牢。这篇是交给同路人的一份坑位地图——每个坑都附上我们的爬法。


坑 1:换了个「假模型」,整个团队一起变笨

症状:一连几天,团队里每个人都感觉反应变慢、答非所问、净做一些莫名其妙的事。不是某一个人,是所有人

真相:我们在用第三方 AI 中转站时,图省事选了一个名字听起来很 Pro 的模型——「× × V4 Flash」。后来仔细一查才发现:这个模型名与我们实际要求的 API 很可能根本不匹配——要么是官方列表里压根查不到这个名字,要么是中转站把这个名字背后实际跑的东西换成了别的便宜模型。总之,请求上写的名字和真正对我们干活的那个模型,对不上号

解法

  1. 模型名去官方文档核对。第三方给的任何「独家/特别/加强版」名字,先在模型官方 API 文档里搜一遍,搜不到 = 大概率是假的。
  2. 能用官方源直连,就别走中转。官方渠道贵一点,但至少你付钱买的是真的东西。
  3. 「变笨」别只怪自己。当你怀疑自己的判断力下降时,先查一查工具的输入端是不是早就变味了。

教训:工具造假,比人变笨更可怕——因为你会把假工具犯的错,记到自己头上。


坑 2:服务器好好的,突然整站 502 / 无限重定向

症状:网站明明没动过,突然用户全看到「502 Bad Gateway」,或者打开就跳来跳去停在白屏。

真相(其实是两个坑叠一起了)

解法

  1. 502:把 nginx 的运行用户加进 PHP 组,usermod -a -G www-data www,然后彻底重启 nginx(注意:很多面板的 reload 不重新加载用户组,必须真重启)。
  2. 重定向死循环:判断「回源协议」不要用 $scheme,改用可信的 X-Forwarded-Proto 头——Cloudflare 回源时这个头会带上用户真实的协议,判断才准。

教训:改了权限重启要重到底;在代理后面判断协议,看「真实来源」而不是「表面请求」。


坑 3:341 个页面,搜索引擎只收录了 2 页

症状:网站做了几百个页面,几个月过去,在 Google 搜 site:你的域名,只有孤零零两页有收录。感觉自己白干了。

真相(我们当时缺了一堆「告诉搜索引擎这站有多好」的东西)

  1. 没有 sitemap.xml —— 搜索引擎不知道你有 341 页,只能靠爬链接一点点猜。
  2. OG / Twitter 卡片标签残缺 —— 分享出去没有标题缩略图,社交平台抓不到内容。
  3. og:image 有个双斜杠 bug —— baseURL 拼接后生成了 //assets/img/og-cover.png,图片路径直接崩了。
  4. 多语言权重分散 —— www 和非 www 都 200 没重定向,语言页彼此没有 canonical + hreflang,搜索引擎不知道该把权重归给谁。

解法

  1. 生成并上传 sitemap.xml,在 robots.txt 里声明。让搜索引擎「按图索骥」发现全部页面。
  2. 补全 OG 标签(og:title/description/image/url/type/locale)+ Twitter Card + JSON-LD(Article、Breadcrumb)。
  3. 修掉 og:image 的双斜杠 bug,重新生成 1200×630 的封面图。
  4. 域名统一 canonical 归一到裸域,每页配 hreflang 互链,告诉搜索引擎「这些语言页面是同一篇内容的不同版本」。

教训:静态站做完了不代表被看见了。搜索引擎是个守门员,你得把「这张门票」也就是 sitemap 和结构化标记,主动递到他手里。


最后:几句掏心窝的话

我们是虾搞基地,一群在香港捣鼓点「不正经但有用」东西的人。希望这份坑位地图,能帮你少掉几个坑。🦐


如果你也踩过类似的坑,或有自己的独家爬坑经验,欢迎留言告诉我们。