剑来札记

之前做过几次公共图床的小活动，都是借用别人的图床。用得多了以后，就一直想做一个真正属于自己的图床。 之前因为发小项目没发到内板，被禁言了三天。也正好趁这几天继续把这个项目完善了一下。 我不是程序员，更多是站在普通用户的角度去打磨这个项目：上传要顺手，外链要好复制，公共上传要能控，相册和图片管理也要够直观。 项目简介 OU-Image Hosting，中文名 欧记图床，是一个面向个人创作者、开发者、小团队和自托管玩家的图床项目。 项目地址：https://github.com/cshaizhihao/ou-image-hosting 它不是网盘，也不是一次性临时上传脚本，而是一个偏长期使用的： 自托管图床 图片库 相册管理面板 公共上传入口 S3 / Cloudflare R2 图片托管工具 一句话概括： 图片放在自己手里，上传、整理、分享都尽量舒服一点。 为什么要做这个项目 很多朋友玩 VPS、独服、小鸡久了以后，都会遇到类似的问题： 截图、教程图、博客图到底放哪里？ 发论坛、写文章、写文档时，图片外链怎么稳定？ 免费图床会不会删图、限流、压缩？ 对象存储很好，但配置起来是不是太麻烦？ 想自己搭一个图床，但不想同时折腾一堆脚本和配置？ 所以有了 OU-Image Hosting / 欧记图床。 它的定位很明确：给 MJJ、博客作者、开发者和小团队用的轻量自托管图床面板。 核心功能 OU-Image Hosting 目前主要支持这些能力： 功能 说明 图片上传 支持拖拽、粘贴、URL 上传和公共上传 外链复制 支持 URL、Markdown、HTML、BBCode 图片管理 支持搜索、筛选、收藏、回收站和批量操作 相册管理 支持创建相册、设置封面、填写描述 权限边界 支持管理员、子管理员、普通用户和访客 存储后端 支持本地存储、Amazon S3、Cloudflare R2、S3-compatible 部署方式 支持 Docker Compose 一键部署 运维能力 支持更新、备份、恢复、回滚、诊断和日志查看 简单说，它就是一个自己可控的图床面板。 新手常见问题 为什么要自建图床？ 主要是为了可控。 ...

博客是最常见的自托管服务之一，但只要放到公网，就不能只考虑“能不能打开”。 下面是一份最小安全清单。 1. 源站只监听本机 如果使用 Cloudflare Tunnel，应用尽量只监听： ```text 127.0.0.1 ``` 不要无意中监听 `0.0.0.0`，否则服务可能绕过 Tunnel 直接暴露在公网。 2. 数据库不要用管理员账号 应用不要长期使用数据库管理员账号。 更好的做法是： 单独创建应用用户； 只授予必要权限； 不把管理员密码写进应用配置。 这样即使应用层出问题，数据库风险也更可控。 3. 后台路径要清楚 前台和后台最好分开规划： ```text / 博客前台 /admin/ 管理后台 ``` 不要让前台代理吞掉后台 API，也不要让后台静态资源被转成 HTML。 4. 定期备份 至少备份两类东西： 数据库； 上传文件。 主题和程序可以重装，文章内容丢了就很麻烦。 5. 保留回滚方案 每次大改之前，先备份配置文件。 自托管系统能长期稳定，不是因为永远不出问题，而是因为出问题后能快速回滚。

Oracle Autonomous Database 默认使用钱包连接。配置不复杂，但错误信息经常不够直观。 最容易踩坑的地方有三个：钱包目录、`TNS_ADMIN`、驱动模式。 钱包目录要完整 钱包目录通常包含这些文件： ```text cwallet.sso ewallet.p12 tnsnames.ora sqlnet.ora ojdbc.properties ``` 程序运行用户必须能读取这些文件。 如果文件存在但权限不对，连接时也会报类似“找不到钱包”或“无法初始化 keystore”的错误。 TNS_ADMIN 指向钱包目录 `TNS_ADMIN` 应该指向钱包所在目录，例如： ```bash export TNS_ADMIN=/opt/oracle-adb/wallet ``` 这样驱动才能找到 `tnsnames.ora`，进而解析连接别名： ```text shibefree01_low ``` Thin 和 Thick 的区别 Node.js 的 `oracledb` 驱动有两种模式： 模式 特点 Thin 不依赖 Oracle Instant Client，部署简单 Thick 需要 Instant Client，但钱包兼容性更好 如果 Thin 模式连接 ADB 钱包出现奇怪错误，可以考虑切到 Thick 模式。 推荐排查顺序 先确认数据库状态是 `AVAILABLE`； 确认钱包文件完整； 确认 `TNS_ADMIN` 指向正确； 用最小脚本执行 `select 1 from dual`； 最后再接入正式应用。 不要一上来就在完整应用里排查。先用最小连接脚本验证数据库通路，会省很多时间。 ...

很多博客系统把前台、后台、主题和插件都放在一个应用里。这样安装方便，但后期改版时经常会互相牵制。 我更喜欢把三件事分开： 前台负责阅读体验； 后台负责内容管理； 数据库负责长期保存。 前台只关心阅读 前台不应该加载复杂的管理脚本，也不需要知道后台权限。它只需要做好几件事： 首页文章列表； 文章详情页； 标签和归档； 搜索； 移动端阅读体验。 这也是为什么静态主题很适合作为博客前台。 后台只关心编辑 后台的任务是让作者舒服地管理内容： 写文章； 改状态； 上传图片； 管理标签； 查看文章列表。 后台可以复杂一些，因为只有管理员使用。 数据库是核心资产 真正有价值的是文章内容，而不是某个主题。 主题可以换，前端框架可以换，后台系统也可以换。但只要数据库里的文章结构清楚，迁移成本就不会太高。 适合谁 这种架构适合愿意折腾一点点的人。它不像 WordPress 那样开箱即用，但长期看更自由。 如果你只是想写文章，WordPress 依然是最省心的选择。 如果你想把博客当作一个长期内容系统，前后端分离会更舒服。

Directus 和 WordPress 的思路不一样。 WordPress 是“博客程序自带一套数据库结构”；Directus 更像是“给现有数据库加一个管理后台”。这让它更灵活，但第一次用时也更不直观。 为什么用 Directus Directus 适合这类场景： 想自己定义数据结构； 需要一个现代后台管理界面； 前台想自由选择技术栈； 数据库不想被某个博客程序锁死。 在博客场景里，可以把文章设计成一个 `posts` 集合。 最小文章结构 一个实用的博客表不需要一开始就复杂： 字段 说明 `title` 文章标题 `slug` URL 里的文章路径 `excerpt` 摘要 `content_md` Markdown 正文 `status` 草稿或发布 `published_at` 发布时间 有了这些字段，前台就可以正常渲染文章列表和详情页。 和 WordPress 的区别 WordPress 的优势是主题和插件生态成熟，上手快。Directus 的优势是数据结构清晰、API 友好、前后端分离更彻底。 如果目标是快速搭一个传统博客，WordPress 更省事。 如果目标是长期维护自己的内容数据，并且未来可能换前端、换主题、换展示方式，Directus 更适合作为内容底座。 Oracle ADB 的角色 Oracle ADB 负责长期保存数据。主题可以换，前台可以换，甚至后台也可以换，但文章数据应该稳定保留。 这也是 Headless 架构最大的好处：内容和展示解耦。

很多自托管服务的问题不在“能不能访问”，而在“暴露以后能不能长期维护”。 Cloudflare Tunnel 的好处是：源站不需要开放公网端口。服务器只要能主动连出 Cloudflare，外部访问就可以通过域名进入服务。 为什么适合家庭服务器和小型 VPS 传统发布方式通常需要： 开放 80/443 端口 配置反向代理 申请和续期证书 维护防火墙规则 面对公网扫描和爆破 使用 Tunnel 后，源站服务可以只监听本机： ```text 127.0.0.1:8088 ``` 这样即使服务器公网 IP 被扫到，Web 服务本身也不会直接暴露。 推荐路径规划 如果一个域名下同时跑前台和后台，路径设计要清楚： 路径 用途 `/` 博客前台 `/posts/*` 文章页 `/admin/*` 管理后台 `/auth/`、`/server/`、`/items/*` 后台 API 前台不要贪心接管所有路径，否则后台 SPA 的资源和 API 很容易被吞掉。 常见坑 1. 后台静态资源 MIME 错误 如果 JS 文件请求到了 HTML，浏览器会报类似错误： ```text Expected a JavaScript module script but the server responded with a MIME type of text/html ``` 这通常是路径被错误转发到了前台首页。 ...