[{"data":1,"prerenderedAt":342},["ShallowReactive",2],{"blog-cache-three-layers":3,"blog-prev-cache-three-layers":127,"blog-next-cache-three-layers":241},{"id":4,"title":5,"author":6,"body":7,"canonical":111,"category":112,"cover":111,"date":113,"description":114,"draft":115,"extension":116,"keywords":111,"meta":117,"navigation":118,"noindex":115,"ogImage":111,"path":119,"seo":120,"seoDescription":111,"seoTitle":111,"stem":121,"tags":122,"updated":111,"__hash__":126},"blog\u002Fblog\u002Fcache-three-layers.md","浏览器、CDN、服务端三层缓存，只配一层等于没配","元析智能",{"type":8,"value":9,"toc":100},"minimark",[10,14,18,21,24,27,30,33,36,39,42,46,49,52,55,58,61,64,67,70,73,76,79,82,85,88,91,94,97],[11,12,13],"p",{},"2026 年 6 月我们接手一个站，首页加载 4.2 秒，查下来是缓存配反了：HTML 缓存一年，JS 和 CSS 缓存五分钟。用户每次访问都在重新下载样式和脚本，而首页本身永远是他一年前看到的版本。",[15,16,17],"h2",{"id":17},"三层缓存各管什么",[11,19,20],{},"浏览器缓存管单个用户，决定他第二次访问要不要重新下载。",[11,22,23],{},"CDN 缓存管一个区域的所有用户，决定请求要不要回到源站。",[11,25,26],{},"服务端缓存管数据，决定每次请求要不要查数据库、拼页面。",[11,28,29],{},"三层都配好，一个老用户访问首页可以只发一次 HTML 请求，其余全命中。",[15,31,32],{"id":32},"浏览器缓存怎么配",[11,34,35],{},"带内容哈希的静态资源，缓存一年，加 immutable。文件名变了 URL 就变了，不用担心更新问题。",[11,37,38],{},"HTML 不缓存或者只缓存几分钟。它是入口，缓存久了用户看不到新内容。",[11,40,41],{},"字体和图片可以长缓存，但要确认 URL 带版本或者哈希。",[15,43,45],{"id":44},"cdn-缓存怎么配","CDN 缓存怎么配",[11,47,48],{},"关键是缓存键。默认按 URL 缓存，如果 URL 里带了没意义的参数，缓存会被打散。",[11,50,51],{},"动态页面要么不缓存，要么用短时间加回源校验。我们一般给 HTML 设 5 分钟，给接口设不缓存。",[11,53,54],{},"还有一点，回源要带压缩。很多站 CDN 到源站这段没开 gzip，白白多传几倍数据。",[15,56,57],{"id":57},"服务端缓存怎么配",[11,59,60],{},"页面级缓存最有效，整页存起来，命中直接返回。",[11,62,63],{},"对象缓存其次，把数据库查询结果存内存。",[11,65,66],{},"数据变了要能主动清缓存，否则内容更新了用户还看到旧的。我们通常用版本号做键，发布时改版本号，旧缓存自然失效。",[15,68,69],{"id":69},"最常见的三种配错",[11,71,72],{},"第一种，就是开头说的两层配反。判断方法很简单，看响应头的 Cache-Control，HTML 和静态资源必须不一样。",[11,74,75],{},"第二种，静态资源文件名没哈希却设了长缓存。发版之后用户还跑旧代码，出了问题很难查。",[11,77,78],{},"第三种，CDN 缓存了带用户信息的页面。这个更危险，A 用户可能看到 B 用户的数据。",[15,80,81],{"id":81},"怎么验证配对了",[11,83,84],{},"用 curl 看响应头，重点看 cache-control、etag、age、x-cache 四个字段。",[11,86,87],{},"age 大于 0 说明命中了 CDN，x-cache 显示 HIT 或 MISS。连续请求同一个静态资源两次，第二次应该全是 HIT。",[11,89,90],{},"再打开 DevTools 的 Network 面板，看 Size 列有没有 from cache。这一步最直观。",[15,92,93],{"id":93},"一个态度",[11,95,96],{},"缓存是性价比最高的性能优化。改配置不写代码，效果立竿见影。",[11,98,99],{},"但它也是最容易出事故的地方。每次改缓存策略，尤其是 HTML 和带用户信息的页面，一定要先在测试环境验证，别直接调到生产。",{"title":101,"searchDepth":102,"depth":102,"links":103},"",2,[104,105,106,107,108,109,110],{"id":17,"depth":102,"text":17},{"id":32,"depth":102,"text":32},{"id":44,"depth":102,"text":45},{"id":57,"depth":102,"text":57},{"id":69,"depth":102,"text":69},{"id":81,"depth":102,"text":81},{"id":93,"depth":102,"text":93},null,"技术SEO","2026-05-24","静态资源该缓存一年，HTML 只该缓存五分钟。我们见过把两层配反的站，用户每次访问都在重新下载。这篇写三层各配什么、怎么配错。",false,"md",{},true,"\u002Fblog\u002Fcache-three-layers",{"title":5,"description":114},"blog\u002Fcache-three-layers",[123,124,125],"缓存","CDN","页面体验","y2rj8uPfGTph9tGcf-y8gYIUZWoYf0TTatwwzpbQ9TM",{"id":128,"title":129,"author":6,"body":130,"canonical":111,"category":112,"cover":111,"date":230,"description":231,"draft":115,"extension":116,"keywords":111,"meta":232,"navigation":118,"noindex":115,"ogImage":111,"path":233,"seo":234,"seoDescription":111,"seoTitle":111,"stem":235,"tags":236,"updated":111,"__hash__":240},"blog\u002Fblog\u002Ftrailing-slash-case-duplicate.md","尾斜杠和大小写：同一页面两个 URL 的隐形重复",{"type":8,"value":131,"toc":221},[132,135,138,141,145,157,160,163,182,185,188,191,202,205,208,212,215,218],[11,133,134],{},"一个页面只应该有一个可访问的 URL 形式。尾斜杠、大小写、index.html、http 与 https、www 与非 www，这五类变体统一在服务器层 301，别让两个都保持 200。听起来是小事，但它造成的重复内容比参数还隐蔽。",[15,136,137],{"id":137},"为什么危险",[11,139,140],{},"搜索引擎需要判断哪个是主版本。外链和分享又散落在不同变体上，权重被切成几份。日志里抓取量被稀释，你以为是收录问题，其实是同一个页被当成三个页在抓。canonical 能救一部分，但它是建议不是强制，服务器层没统一就一直在漏。",[15,142,144],{"id":143},"_2026-年-1-月那次","2026 年 1 月那次",[11,146,147,148,152,153,156],{},"一个开发者工具站，文档页同时存在 ",[149,150,151],"code",{},"\u002FDocs\u002FAPI\u002F"," 和 ",[149,154,155],{},"\u002Fdocs\u002Fapi"," 两种形式，站内链接混用，外部链接也混着来。GSC 里 60% 的文档页报了\"重复网页，用户未选定规范网页\"。",[11,158,159],{},"统一成全小写、无尾斜杠之后，一个月重复网页从 60% 降到 8%，文档页的收录率从 55% 涨到 79%。改动就是 nginx 里三条规则。",[15,161,162],{"id":162},"五类变体的处理顺序",[164,165,166,170,173,176,179],"ol",{},[167,168,169],"li",{},"http 全部 301 到 https，一次跳到位。",[167,171,172],{},"裸域 301 到 www（或者反过来，选一个，别两个都行）。",[167,174,175],{},"大写 301 到小写。",[167,177,178],{},"尾斜杠统一：目录类路径统一无斜杠，或者统一带斜杠，二选一。",[167,180,181],{},"index.html 折叠到目录，301 过去。",[11,183,184],{},"顺序有讲究：先做协议和主机名，再做路径层。不然会出一条链跳三四次。",[11,186,187],{},"我们给客户定这条规则时，会顺手把 CDN 的缓存键也一起看：如果缓存键包含大小写或尾斜杠，同一个页面会在边缘节点缓存成多份，命中率下降，回源请求变多，本质上和重复 URL 是同一个问题。",[15,189,190],{"id":190},"服务器层怎么写",[11,192,193,194,197,198,201],{},"nginx 用 ",[149,195,196],{},"return 301"," 或 ",[149,199,200],{},"try_files"," 组合，Apache 用 mod_rewrite，CDN 层也要检查一遍，很多人只改了源站，边缘节点还返回旧结果。静态站生成器要统一 URL 输出规则，别让不同页面类型生成不同形式。",[15,203,204],{"id":204},"验证方法",[11,206,207],{},"curl 每个变体看返回码和 Location；Screaming Frog 爬一遍看有没有 301 和重复标题；GSC 网址检查确认 canonical 和最终 URL 一致。这三步花不到一小时。",[15,209,211],{"id":210},"和-canonical-的关系","和 canonical 的关系",[11,213,214],{},"服务器统一和 canonical 是两道防线，不是二选一。服务器层解决了大部分变体，canonical 兜住那些没法重定向的情况，比如参数变体、跨域镜像。只靠 canonical 不做重定向，蜘蛛每次还是会请求多个变体，抓取预算照样被切碎。",[15,216,217],{"id":217},"立场",[11,219,220],{},"这不是小事。一个站点三种 URL 形式，等于把权重分三份，再努力也是三分之一。统一规则的收益比多写十篇文章快。",{"title":101,"searchDepth":102,"depth":102,"links":222},[223,224,225,226,227,228,229],{"id":137,"depth":102,"text":137},{"id":143,"depth":102,"text":144},{"id":162,"depth":102,"text":162},{"id":190,"depth":102,"text":190},{"id":204,"depth":102,"text":204},{"id":210,"depth":102,"text":211},{"id":217,"depth":102,"text":217},"2026-05-23","\u002Fdocs\u002Fapi 和 \u002Fdocs\u002Fapi\u002F 是不是同一页，\u002FAbout 和 \u002Fabout 呢？这两类重复比参数更隐蔽。这篇给服务器层的统一规则、五类变体的处理顺序，以及一个 2026 年 1 月的修复记录。",{},"\u002Fblog\u002Ftrailing-slash-case-duplicate",{"title":129,"description":231},"blog\u002Ftrailing-slash-case-duplicate",[237,238,239],"URL设计","重复内容",301,"jRlViDM6rOiCWw4iVh3ooY6pmG4fGkmXp82FxlJoabo",{"id":242,"title":243,"author":6,"body":244,"canonical":111,"category":330,"cover":111,"date":331,"description":332,"draft":115,"extension":116,"keywords":111,"meta":333,"navigation":118,"noindex":115,"ogImage":111,"path":334,"seo":335,"seoDescription":111,"seoTitle":111,"stem":336,"tags":337,"updated":111,"__hash__":341},"blog\u002Fblog\u002Fbatch-writing-workflow.md","一天写四篇：我们的批量写作流程和它的代价",{"type":8,"value":245,"toc":321},[246,249,252,255,258,261,264,267,270,273,276,279,282,285,288,291,294,297,300,303,306,309,312,315,318],[11,247,248],{},"一天写四篇，不是四篇都在从零想。我们的批量日是这么排的：上午两篇结构固定的短稿，下午两篇要查资料的，晚上不回看，第二天统一改。2026 年 3 月试了一整月，产出 15 篇，是平时的两倍多。",[15,250,251],{"id":251},"提前一周把事做完",[11,253,254],{},"选题、素材、模板，全部在前一周定好。批量日当天不查词、不定题、不找图，只写。",[11,256,257],{},"素材包里每篇要有：三个必须回答的问题、一个独家信息、两张截图或一段代码。缺一样，这篇当天写不了。",[15,259,260],{"id":260},"上午写短的",[11,262,263],{},"上午的两篇是 800 到 1000 字的短稿，结构固定：结论、三个小节、一个清单。这类内容不需要太多思考，写得快。",[11,265,266],{},"我上午能写两篇，中间休息 20 分钟。速度来自结构固定，不是打字快。",[15,268,269],{"id":269},"下午写要查资料的",[11,271,272],{},"下午的两篇通常是数据文或教程，需要翻后台、跑数、看文档。一篇要两到三小时。",[11,274,275],{},"这两篇写完当天不追求完美，能出完整初稿就算完成。",[15,277,278],{"id":278},"第二天统一改",[11,280,281],{},"批量日不修改，第二天上午花两小时统一过一遍：删废话、补第一人称、检查有没有独家信息。",[11,283,284],{},"隔一夜再看，能砍掉的东西比当天多。当天觉得必要的段落，第二天往往一眼就知道该删。",[15,286,287],{"id":287},"代价是什么",[11,289,290],{},"第一个月的代价很明显：数据文比例从 30% 降到 12%，全是结构化的短稿。阅读完成率掉了 9 个百分点。",[11,292,293],{},"第二个月我们把批量日改成两周一次，数据文单独安排，情况才平衡。",[15,295,296],{"id":296},"什么内容不适合批量",[11,298,299],{},"需要实测的、需要采访客户的、需要跑对比实验的，一天最多一篇。硬塞进批量日，出来的东西一定是空壳。",[11,301,302],{},"我们的分工是：批量日写“已知答案”的题，单独安排写“需要找答案”的题。",[15,304,305],{"id":305},"给一个人团队的建议",[11,307,308],{},"先别追求四篇。能稳定一天两篇、每周两天，一个月也有 16 篇，够用。",[11,310,311],{},"另外，批量日之后一定要留一天不写。连续两天四篇，第三天的稿子质量明显下滑，这个我自己试过两次，两次都一样。",[11,313,314],{},"我们后来把批量日固定成每两周一次，平时一天一篇。这样既有集中产出的效率，也不会把内容质量压平。",[11,316,317],{},"如果你的选题里一半以上需要查资料，批量日就不适合你。先算一下比例，再决定要不要这么做。",[11,319,320],{},"批量写作的价值在减少切换成本，不在追求数量。切换一次大脑要 20 分钟，一天切八次，什么都写不出来。",{"title":101,"searchDepth":102,"depth":102,"links":322},[323,324,325,326,327,328,329],{"id":251,"depth":102,"text":251},{"id":260,"depth":102,"text":260},{"id":269,"depth":102,"text":269},{"id":278,"depth":102,"text":278},{"id":287,"depth":102,"text":287},{"id":296,"depth":102,"text":296},{"id":305,"depth":102,"text":305},"内容运营","2026-05-25","一天四篇不是四篇都在写。我们上午写两篇结构固定的短稿，下午写两篇要查资料的，晚上不回看。试了一个月产出 15 篇，但也暴露了代价。",{},"\u002Fblog\u002Fbatch-writing-workflow",{"title":243,"description":332},"blog\u002Fbatch-writing-workflow",[338,339,340],"内容生产","写作流程","小团队","puckOWYLJ3lsdH2i69ZkDM35fE7R4ntcs-W1aVLW4wA",1794088105359]