Nskdfh 的博客

关于SpringBoot中拦截器和过滤器的关系

Mon, 05 Oct 2026 00:00:00 GMT

Filter

首先是过滤器（Filter），是Servlet中定义的一个规范，也就是说依赖tomcat等容器，只能在web程序中使用，用来拦截和处理http的请求，过滤器可以对请求进行预处理，也可以对响应进行后处理。过滤器的主要作用是在请求到达Controller之前或响应离开Controller之后，对请求和响应进行处理。

使用方法

首先导入servlet库，因为需要我们来实现当前这个接口，会重写3个主要方法，

示例代码如下

import javax.servlet.*;
import java.io.IOException;
public class MyFilter implements Filter {
   @Override
   public void init(FilterConfig filterConfig) throws ServletException {
       System.out.println("MyFilter初始化");
   }
   @Override
   public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
       System.out.println("MyFilter拦截请求");
       chain.doFilter(request, response); // 继续执行后续过滤器或Controller方法
       System.out.println("MyFilter处理响应");
   }
   @Override
   public void destroy() {
       System.out.println("MyFilter销毁");
   }
}

Interceptor

拦截器是Spring中的一个组件，有spring容器来管理，不用依赖tomcat，用于拦截和处理HTTP请求。拦截器可以对请求进行预处理，也可以对响应进行后处理。拦截器的主要作用是在请求到达Controller之前或响应离开Controller之后，对请求和响应进行处理。

使用方法

这次是实现

示例代码如下

import org.springframework.web.servlet.HandlerInterceptor;
import org.springframework.web.servlet.ModelAndView;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class MyInterceptor implements HandlerInterceptor {
   @Override
   public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
       System.out.println("MyInterceptor拦截请求");
       return true; // 返回true表示放行，返回false表示拦截请求并终止后续处理流程
   }
   @Override
   public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {
       System.out.println("MyInterceptor处理响应");
   }
}

Filter 与 Interceptor 区别

1.接口规范不同：过滤器需要实现Filter接口，而拦截器需要实现HandlerInterceptor接口。

2.拦截范围不同：过滤器Filter会拦截所有的资源，而Interceptor只会拦截Spring环境中的资源。

卡了我半天的那些坑（顺便聊聊 vibe coding）

Sat, 19 Sep 2026 00:00:00 GMT

这是「搭建这个博客」系列的第 3 篇。前两篇是 1 从零搭一个博客和 2 给静态博客接一个能登录的后台。

前两篇讲的是"怎么做对的"。这篇讲"怎么错的"——而且我保证，这一篇比前两篇有用。

顺便说一句：整个博客是我和 AI 协作做的（也就是现在说的 vibe coding）。下面这些坑，有一半是它帮我找到的，也有一半是它先带偏、后来才被我拽回来的。最后一节专门聊这件事。

坑 1：一个字符抄错，GitHub 直接给我 404

配 OAuth 的时候，我从 GitHub 页面上把 Client ID 手动敲进了 Cloudflare 的环境变量。

然后点登录：打开 GitHub 授权页 → 404，一只沙漠里的猫告诉我"This is not the web page you are looking for"。

最要命的是这个错的表现形式，它几乎把所有常规排查方向都指向了错误的地方：

如果我没登录 GitHub，打开那个授权地址，它会正常跳转到登录页——看起来"授权页是通的"！
只有登录之后，GitHub 才真正处理这个授权请求，这时才发现找不到这个应用 → 404

于是接下来的一个多小时，我依次怀疑并排查了：网络被墙、浏览器缓存、油猴脚本、代理软件、DNS、hosts……一个都不是。

真正的原因是：我把第 5 位的小写字母 l 敲成了数字 1，还漏掉了一个字符——19 位，而正确的是 20 位。

教训：

Client ID / Client Secret 这类东西，永远用复制按钮，不要手打。它们的字符集里全是 l / 1 / I、O / 0 这种长得一模一样的东西。
自检方法：这类 client ID 通常是 20 位。长度不对，基本就是抄错了。
排查顺序：先怀疑自己刚输入的东西，再怀疑环境。我是反着来的，所以白花了一个多小时。

坑 2：无刷新跳转，把页面卡在了半截

Fuwari 用 Swup 做无刷新页面切换——点站内链接时不整页刷新，只把 <main> 里的内容换掉。体验确实好，但有个前提：目标页面得有 <main> 容器。

而后台页面（CMS）是独立的单页应用，压根没有 <main>。

于是点导航里指向后台的链接时，浏览器控制台里出现：

[swup] Container missing in incoming document: main
[swup] Container mismatch, aborting

Swup 一看容器对不上 → 把整个跳转中止了 → 页面就停在"切了一半"的状态，导航栏上打开的浮层也跟着挂在那儿不动。

这也是我一开始判断错的地方：我以为是"面板关闭逻辑写错了"，改了好几轮都没用。因为问题根本不在关闭逻辑，而在"跳转失败了"。

解决：给指向后台的链接加一个 data-no-swup 属性（这是 Swup 的忽略标记），让它老老实实整页加载。后台本来就是独立应用，整页加载才是对的。

坑 3：bfcache 让"已经关掉"的面板又活了

我做了个导航栏浮层面板，逻辑是"打开时关掉别人，离开页面时关掉自己"。听起来没毛病。

但浏览器前进后退的时候出问题了：

你点了链接离开 → pagehide 触发 → 代码把状态设成「关闭」
                                  ↓ 但框架是异步更新 DOM 的
                          浏览器立刻把页面冻结进 bfcache
                          （DOM 上还是「打开」的样子）
                                  ↓ 你按了后退，页面从缓存里被恢复
                  状态已经是「关闭」→ 框架认为没变化 → 永远不再渲染
                                  ↓
                  面板就永久卡在打开的样子，只有刷新能救

关键点在于：bfcache 冻结页面时，JS 状态和 DOM 会一起被原样保存，而且 pagehide 之后留给你的时间非常短。你改了状态，但框架还没把 DOM 更新出来，页面就已经被冻住了。

解决：不要依赖框架重渲染——直接操作 DOM 类名（classList.add(...)），并且在 pageshow 时再对齐一次。

普遍启示：任何"离开页面时改状态"的逻辑，都要考虑 bfcache。这不是框架的 bug，是浏览器的正常行为。

坑 4：改了环境变量，必须重新部署

这个纯属不知道就会踩：Cloudflare 不会把新填的环境变量自动应用到已经跑着的 Functions 上。

现象是：变量明明填对了，接口却一直报"未配置"。去部署页面点一次"重新部署"就好了。

坑 5："代码没生效"十有八九是浏览器在跑旧代码

调试期间反复出现"我明明改了，怎么还是老样子"。后来发现是两类原因：

开发服务器的热更新（HMR）能更新模板和状态，但不重新绑定已经挂载的组件的事件逻辑。你改了事件处理，页面不整页刷新就还是旧的。
浏览器前进后退会恢复缓存页面，看起来就像"我刚改的东西消失了"。

解决：我在组件里加了一行版本标记——window.__adminMenuV = "v6"。不确定当前页面跑的是哪一版，控制台敲一下就知道。就这一行，省了后面大量的"到底生效了没"的扯皮。

坑 6：我自己的测试，把我自己骗了

这条最值得说，因为它跟代码无关，跟"怎么确认问题真的解决了"有关。

修完 bfcache 那个 bug 之后，我写了个自动化测试来验证。测试通过了。但线上问题还在。

原因是我用脚本合成的 pagehide / pageshow 事件去模拟"前进后退"。而合成事件根本不会触发真正的页面冻结——于是 DOM 更新有充足的时间跑完，那个 bug 自然复现不出来。测试给了我一个绿色的假象。

后来我把测试改成两条硬要求：

用真实的导航：location.href 真的跳走，再 history.back() 真的回来
断言"这次确实走了 bfcache"：在 pageshow 里记录 event.persisted，如果它没变成 true，这次测试就不算数

改完之后测试才真正有价值——它才真的在测那条会出问题的路径。

教训：测试通过 ≠ 问题解决，尤其是当测试自己构造了运行环境的时候。多问一句："我这么测，有没有可能绕过了真实路径？"

关于 vibe coding：它改变了什么，又要求什么

这个博客是我和 AI 协作做的。整个过程里我几乎没手写代码，但每一步都在做判断。

它确实很能打

一个下午搞定整个站点的汉化、配置、若干交互组件
几十行写出并部署了 OAuth 代理，还顺手做了 CSRF、白名单、最小权限
排查问题时能快速给出可验证的假设（例如"直连返回 302、走代理返回 404，所以问题在本机代理"——这个假设完全正确，一下省了我半小时）

放在以前，这些事情的时间成本大概是这里的几倍。

但它有硬性要求

1. 验证权必须留在人手里。 它会非常自信地给结论，包括错的结论。这一轮里它先后把问题归因于"缓存""浏览器扩展""本机代理"，全都不是。关键结论自己复现一遍，这是底线。

2. 凭据永远不进仓库、不进聊天。 Client Secret、访问令牌这类东西只能待在部署平台的环境变量里。我中途把 secret 截图发出去过，事后只能作废重发。能不发就不发。

3. 小步提交，保持可回滚。 每次改动独立成一次提交，写清"改了什么、为什么"。出问题时能一眼定位到是哪一步引入的——这一条救过我不止一次。

4. 让它承认"我不确定"。 比"答错了"更危险的是"答得很顺但你没法验证"。所以我会强制它给依据：日志、状态码、测试结果。没有证据的结论，一律当假设。

5. 关键代码你得看得懂。 不用逐行懂，但安全相关的必须懂：谁能拿到 token、白名单在哪校验、secret 存在哪。看不懂的地方，就不该让它上线。

6. 文档要写"为什么"。 我把踩过的坑和排查方法都写进仓库的 docs/ 了。三个月后的我，或者下一个接手的人，能少走一遍。

7. 接受"它会自信地犯错"，并据此设计流程。 所以要有版本标记、要有可复现的测试、要有能回滚的提交历史。这些不是仪式感，是保险。

我的结论

vibe coding 没有让"懂技术"变得不重要。恰恰相反，它把人的角色从"实现者"推到了"审查者"——而审查需要的判断力一点不比写代码少：

看得出方案哪里不对
读得懂报错在说什么
问得出"这个测试有没有绕过真实路径"
守得住"凭据不进仓库"这种底线

它能极大压缩"实现"的时间，但压缩不了"判断"的责任。

最后

这三篇写下来，其实我想说的就一句：搭博客这件事，现在真的不难了。难的是那些"看起来好了其实没好"的时刻——而对付它们，靠的不是更聪明的工具，是更笨的验证。

如果你也在搭，希望这几篇能帮你少花一个多小时。

系列导航：1 从零搭一个博客 · 2 给静态博客接一个能登录的后台 · 3 卡了我半天的那些坑

给静态博客接一个能登录的后台

Fri, 18 Sep 2026 00:00:00 GMT

这是「搭建这个博客」系列的第 2 篇。另外两篇是 1 从零搭一个博客和 3 卡了我半天的那些坑。

静态博客唯一不爽的地方

上一篇说到，我选了静态博客，好处一大堆。但它有个很实在的问题：

想写篇文章，得打开编辑器、新建 Markdown、写完、然后 push。

在自己电脑上还好，但我经常在别的设备上（手机、公司电脑），那就很难受了——总不能在手机上装个 Git 客户端写文章吧。

所以我想给它补一个后台：打开网页，登录，写，保存。写完自动就是一次提交，Cloudflare 自动部署。对，就是 WordPress 那种体验，但不想要 WordPress 那一整套服务器。

思路：基于 Git 的前端 CMS

这类工具不少，统称"Git-based CMS"（以前的 Netlify CMS、Decap CMS、现在的 Sveltia CMS 都属于这一类）。

它的原理其实特别简单：

它本身就是几个静态文件，挂在 /admin/ 路径下（不需要任何服务器）
配置写在 public/admin/config.yml：你的仓库、分支、有哪些内容类型、每个字段叫什么
登录之后，它直接调 GitHub API 往你的仓库提交文件

所以**"保存" = 一次 commit = 一次自动部署**。跟手动 push 的结果一模一样，只是把过程变成了点按钮。

我选的是 Sveltia CMS：界面比老牌的 Decap 现代很多，中文也正常，作者还在活跃维护。版本我是锁死的（不写 latest），免得上游更新把我这边弄挂。

文章在仓库里长什么样

后台里每篇文章，对应仓库里一个文件夹：

src/content/posts/
└── blog-admin/
    ├── index.md      ← 正文 + frontmatter
    └── cover.webp    ← 封面图（可选，放同一层）

好处是每篇文章的图片跟着文章走，不会越堆越乱。后台里拖一张封面图进去，它自动就存到这篇文章自己的文件夹里。

登录：两种方式，我都要

Sveltia 支持两种登录：

第一种：访问令牌。 去 GitHub 手动创建一个 40 位的 token，粘贴进后台。优点是不需要任何后端，缺点是麻烦（要手动建、到期要换）。

第二种：GitHub 授权登录。 点一下按钮就进来了。但它有个前提：需要一个能安全保存 client secret 的地方——因为拿授权码换 token 这一步必须带 secret，而 secret 绝对不能放在前端（放前端等于公开）。

问题就来了：我这是纯静态站，没有后端。

于是用 Cloudflare 写了个小代理

好在站点已经部署在 Cloudflare Pages 上了，它支持 Functions：在仓库里建一个 functions/ 目录，里面的文件会自动变成服务端接口。

于是整个登录流程被我拆成两个接口（一共几十行代码）：

/api/auth      → 生成一个随机 state，种下 CSRF cookie，302 跳转到 GitHub 授权页
/api/callback  → 校验 state 和 cookie → 用 code 换 token（secret 只在服务端）
               → 用 token 查一下用户名 → 和白名单比对 → 通过才把 token 交给后台页面

为什么中间要绕一圈，不直接把 token 给前端？因为我要先确认"是谁"：

在 callback 里，函数拿着 token 去问一次 GitHub"这是谁"，拿到用户名，和我配置的白名单比对。不是我本人，token 根本不会发出去——这样即使别人知道了后台地址、也完成了授权，他什么也拿不到。

安全上具体做了四件事：

state + CSRF cookie 双重校验：防止有人伪造回调地址来骗 token
用户名白名单：只允许指定的 GitHub 账号登录
权限最小化：申请的 scope 只有 public_repo（我的仓库是公开的，这就够了），授权页上明确显示"仅公开仓库"
secret 只存在 Cloudflare 的环境变量里：不进仓库、不进浏览器、不写进任何文件

顺便说，函数在失败时会返回明确的错误码和中文提示，后台界面直接把原因显示出来——排查的时候特别省事（这一点在第 3 篇里救了我不止一次）。

Cloudflare 上要配的东西

就四个环境变量：

变量	作用
`GITHUB_CLIENT_ID`	你 OAuth 应用的 Client ID
`GITHUB_CLIENT_SECRET`	对应的 Secret
`ALLOWED_GITHUB_LOGIN`	白名单：允许登录的 GitHub 用户名
`ALLOWED_DOMAINS`	只允许你自己的域名使用这个代理

有个特别容易踩的坑：Cloudflare 不会把新填的环境变量自动应用到已经跑着的函数上。填完必须去"部署"页面点一次重新部署，否则函数读到的还是旧值——现象就是"明明填了变量，接口却一直报未配置"。

（另外：Client ID 和 Secret 一定要用复制按钮，别手打。我手打的后果，第 3 篇里详细写了。）

现在的写作流程

打开 你的域名/admin/ → 点"使用 GitHub 登录" → 授权 → 写 → 保存。

然后就没了。后台会提交、Cloudflare 会自动部署，一分钟左右文章就上线了。

手机上也能这么写——这大概是我最满意的一点。

下一篇是这个系列里最"血泪"的一篇：几个把我卡了半天的坑，以及我怎么被自己的测试骗了一次。

系列导航：1 从零搭一个博客 · 2 给静态博客接一个能登录的后台 · 3 卡了我半天的那些坑

从零搭一个博客：为什么我最后选了 Astro

Thu, 17 Sep 2026 00:00:00 GMT

这是「搭建这个博客」系列的第 1 篇。另外两篇是 2 给静态博客接一个能登录的后台和 3 卡了我半天的那些坑。

起因

说简单点：我想要一个自己的地方写字。

不想发在别人的平台上——排版不能改、数据不在自己手里、说不定哪天就没了。所以决定自己搭一个。

我不是前端工程师，平时也就写写脚本。所以我给自己定的要求很低：能跑起来、好看、以后写文章不折腾。

先把 WordPress 排除掉

第一反应当然是 WordPress，毕竟"建站"两个字搜索引擎第一个推的就是它。

但想了下我的实际需求：我就写点技术笔记，一年可能几十篇。为了这个去租服务器、装 PHP、配数据库、装插件、还得记着升级和备份——服务器一旦不维护，就是被挂马的重灾区。

相比之下，静态博客的好处太明显了：

页面是提前生成好的纯静态文件，快
扔到 CDN 上就行，免费
没有数据库、没有后台入口，几乎没什么可攻击的
文章就是 Markdown 文件，在 Git 里，永远不会丢

它唯一的问题就是：写文章要改文件、还要 push。这个后面我专门写了一篇解决它（就是本系列第 2 篇）。

为什么是 Astro + Fuwari

框架我看了 Hugo、Hexo、Astro。最后选 Astro 的原因很朴素：

它默认就是静态生成，不用我去理解什么渲染模式
生态好，图片优化、代码高亮、搜索、站点地图都有现成集成
想加点交互组件也不难（它支持 Svelte / React 这些）

主题选了 Fuwari（开源，MIT）。原因更朴素：一眼看过去顺眼——左边个人卡、右边文章列表，二次元风格的封面图，暗色模式也好看。

选主题这事我建议别纠结太久。好看、能改，就够了。反正代码在自己手里，不满意随时换。

第 1 步：本地先跑起来

git clone <主题仓库> 我的博客
cd 我的博客
pnpm install
pnpm dev

需要 Node 20+ 和 pnpm。跑起来后打开 http://localhost:4321 就能看到默认样子。

这里有个小建议：先别急着改东西，先跑一遍 pnpm build 和 pnpm preview，确认"原样是能构建的"。不然一会儿改坏了，你分不清是环境问题还是自己改错了。

第 2 步：把它变成"我的"博客

Fuwari 把所有能改的东西都集中在一个文件里：src/config.ts。

站点标题、副标题、语言（我改成 zh_CN）、主题色、banner 大图、头像、导航栏、社交链接、每页显示几篇文章、音乐播放器……全在这儿。改这一个文件，站点的"身份"就变了。

我的做法是：先把这里改到自己满意，再动别的。因为后面改组件的时候，你会需要一个"确定没问题"的基线。

第 3 步：汉化（有个小坑）

主题自带多语言，中文文案在 src/i18n/languages/zh_CN.ts。改文案很直接。

但如果你要新增一个词条，注意了：不是只改中文文件就行。得先在 i18nKey.ts 里加 key，然后把全部 10 个语言文件都补上——少一个就是构建报错（类型检查过不去）。

我第一次就是这么踩的：改完中文，一构建，红字一片。

第 4 步：部署上线（免费）

代码推到自己 GitHub 仓库后：

Cloudflare Dashboard → Workers & Pages → 创建 Pages 项目 → 连接这个仓库
构建命令填 pnpm run build，输出目录填 dist
绑定自己的域名，HTTPS 证书 Cloudflare 自动签

然后你会发现一件很爽的事：以后每次 git push，它自动重新构建部署，一分钟左右就上线。

这个"提交即上线"的闭环特别重要——它让后面加后台变成可能（后台写完文章 = 一次提交 = 自动部署）。

现在的样子

搭完之后陆陆续续又加了些东西：侧栏加了文章/分类/标签的统计、补了两个总览页、右下角加了回到顶部、侧栏塞了个音乐播放器。都是小东西，但用起来舒服很多。

整个过程最大的感受是：别追求一次到位。先上线一个能用的，再慢慢加。

下一篇讲怎么给这个纯静态的站接一个能登录的后台，让它变得"能写"。

系列导航：1 从零搭一个博客 · 2 给静态博客接一个能登录的后台 · 3 卡了我半天的那些坑