Loading......
朋友们的最新动态
作者在搭建个人网站时，一直在寻找一款满足界面简洁、部署简单、分类明了且稳定好用等要求的图床服务。他先后尝试了功能丰富但存在外链问题的兰空图床，以及部署简单但功能过于基础的简单图床，均不理想。最终，他发现了基于Go和Vue.js构建的初春图床（oneimg），其界面干净、资源占用小，虽没有传统文件夹分类，但灵活的标签管理更适配个人创作场景。然而，该图床与Halo博客系统并无现成对接方案。为解决此问题，作者利用AI工具开发了oneimg-halo-plugin插件，实现了在Halo后台直接使用初春图床作为附件存储策略，完成图片的上传、同步与链接插入，最终打造了一个无缝衔接的个人图床与博客写作工作流。
上线博客的日子 2026/7/9
一次意外的上行异常排查，竟发现电脑中藏着一个使用内核驱动抓包的后台服务。海康威视的设备搜索工具SADP实质上是WinPcap驱动的抓包程序，持续上传网络流量至云端，占用5GB缓存且无法正常卸载。本文详细记录排查与清理过程，揭秘这种越界行为。
守护人们的笑容 假面骑士空我 结构化深度解析
2026 年 7 月 9 日 · 数据恢复纪实 评论丢了 上一篇文章讲到 git reset --hard 覆盖了 WAL 文件导致数据库清空，靠凌晨 3 点的自动备份恢复了 45 篇文章和 167 条动态。当时以为数据全部救回来了。 直到有人反馈：「昨天晚上的一些评论没了」 一查数据库，评论表最大 ID 是 311，最后一条停在 7 月 8 日上午 11:21。但 nginx 访问日志清楚地记录着——7 月 8 日下午到晚上，还有 10 条评论 POST 请求。 也就是说，311 号到 320 号之间的 9 条评论，在备份里就不存在。备份本身就不完整。 为什么备份没有这些评论？ 答案藏在 SQLite 的 WAL 模式里。 WAL 模式的工作原理 SQLite 的 WAL（Write-Ahead Logging）模式下，写入操作不会直接写主数据库文件，而是先写到 blog.db-wal 日志文件中。只有当日志文件达到一定大小（默认 1000 页 ≈ 4MB），或手动执行 PRAGMA wal_checkpoint 时，数据才会合并（checkpoint）到主库 blog.db。 写入
数据库被 git reset 覆盖后，9 条评论随之蒸发。备份脚本只 cp 了主库没管 WAL，凌晨三点的备份形同虚设。先从收件箱的评论通知邮件里捞回 4 条访客评论，本以为剩下 5 条永久丢失——直到发现已发送文件夹里的回复通知邮件，把博主自己的评论也全捞了回来。9 条，一条没少。
45 篇文章、167 条动态、143 条评论——一瞬间全部消失。罪魁祸首竟是一个被 git 跟踪的 WAL 文件。本文从发现、排查、定位到修复，完整复盘这次生产事故。
2026 年 7 月 9 日 · 一次惊心动魄的线上事故 事故发生 今天凌晨在检查博客的 RSS 订阅功能时，顺手测了一下 API，结果看到了令人血压飙升的一幕： // GET /api/articles?page=1&limit=2 {"rows":[],"total":0,"page":1,"limit":2} // GET /api/moments?limit=2 {"rows":[],"total":0,"page":"2","totalPages":0} 所有数据都没了。 文章、动态、评论——全部返回空数组。赶紧登上服务器查数据库： $ node -e "import Database from 'better-sqlite3'; const db = new Database('data/blog.db', { readonly: true }); console.log('articles:', db.prepare('SELECT COUNT(*) as c FROM articles').get().c); console.log('moments:', db.pr
本系列终章以借书和还书操作为例，阐述跨表事务的原子性是如何成为数据层闭环的最后拼图。借书须在同一个异步会话内，将图书状态改为“借出”并新增借阅记录，通过一次 `await db.commit()` 提交，避免图书被标记借出却缺失记录的不一致状态；还书同样需原子性地填充归还时间并复位图书状态。文章定义了 `Borrow` 模型与借还 DAO 事务实现，并点明高并发下需用 `SELECT FOR UPDATE` 行锁、时间字段统一使用 UTC 及软删除过滤等避坑要点。全文回顾了异步栈下四条一致规律：DAO 函数皆为 `async def`、Engine 应用级单例、Session 请求级作用域、事务边界显式控制，并将第 03 章至第 19 章的 CRUD 主干与跨表事务收束为完整的数据层闭环。
刚开始想着LLM模拟达妮娅一天的行为，每天自动随机时间生图后发送推文。可惜不能部署到服务器上，2核2g的服务器根本跑不了图！
以前项目习惯直接丢一个纯静态的404.html，但既然这是个人网站，那必须把elegant安排上！
本文阐述在图书管理API中采用软删除方案，将删除操作转换为UPDATE语句，在deleted_at列写入UTC时间戳而非物理删除，以实现数据可逆恢复与审计完整。所有面向用户的查询必须在DAO层统一附加deleted_at IS NULL过滤，确保已删除行对业务透明，避免幽灵数据。删除时使用SQLAlchemy Core的update，根据rowcount判断资源是否存在或已被删除，统一抛出NotFoundError并返回404。为提升性能，建立(deleted_at,id)复合索引，使未删除记录的过滤与排序均能高效利用索引。此外，特别强调了应用层生成时间戳的语义优势、全局查询过滤的一致性，以及唯一索引冲突和定期清理墓碑行等注意事项。