做网址导航站，常规做法是找个导航 CMS：新建分类表、站点表、标签表，前台写一套模板，后台再写一套管理界面。做得越像样，工作量越接近一个小型 CMS。ITEM 走的是另一条路——它不建新表，全部塞进 Typecho 的文章里，靠自定义字段区分「这是篇文章」还是「这是一个网址」。装一个 Typecho，启用主题，剩下的就是发文章。
项目在 GitHub 上叫 fordes123/ITEM，GPL-3.0 协议，PHP 编写，2024 年 2 月 22 日建仓，截至 2026 年 11 月约 201 星、43 个 fork、0 个未关闭 issue，仓库约 5 MB（含构建产物），最新一版是 v2.1.0（2026 年 5 月 25 日），今天仍有提交。作者还给了一个 Hugo 版 hugo-theme-item，说明这套东西的设计已经稳定到可以移植。
一、长得像仪表盘的导航站
打开示例站，第一眼是左边一条竖排分类（人工智能、影音视听、游戏仓库、工具在线、软件系统、网上冲浪、知识学习、图片素材、资源下载），每个分类配一个 Font Awesome 图标。中间第一屏是三块内容：「热门站点」按顺序列出站点名与一句话介绍，「工具直达」是八个彩色图标组成的宫格，「天气」组件显示温度、体感、湿度、风力与空气质量。往下滚才是按分类组织的站点卡片。
搜索栏那一行值得单独说：它不是单一的站内搜索，而是一排可切换的入口——站内、谷歌、Yandex、图书、Steam、视频站、磁力链接，每个入口在后台都是一个 JSON 项，想加就加。这类设计对「导航站当浏览器首页」的使用方式特别对味。
响应式做得比较彻底：桌面端是「左栏 + 内容」，移动端把左栏收成抽屉，工具宫格从两行变一行两列，搜索栏的入口横向滚动。效果图里那台手机就是窄屏下的样子。
二、数据模型：一篇文章 = 一个条目
这是整个主题最值得讲的设计。它没有为「网站」单独建表，而是复用 Typecho 的 contents 表，用自定义字段描述不同类型的条目：
| 内容类型 | 怎么产生 | 前端表现 |
|---|---|---|
| 站内文章 | 普通发布，不带导航字段 | 走主题的文章模板，正常阅读页 |
| 网址导航 | 填写「跳转地址」等字段 | 首页一张站点卡，点击直接跳转到该地址 |
| 微信小程序 | 跳转地址填二维码图片地址 | 详情页展示二维码与进入入口 |
配套的字段有：跳转地址、简单介绍、图标 URL、站点评分、SEO 关键词、SEO 描述、密码提示。分类决定首页结构——一级分类出现在侧边栏，子分类可以选择平铺或者收纳进折叠区；分类的「略缩名」用来映射图标，比如填 book 就会渲染出 Font Awesome 的书本图标。
这套设计的取舍很清晰。好处是不动数据库结构：换主题、导出、备份、迁移，走的还是 Typecho 原生那一套，不会因为主题换了就留下几张孤儿表。代价是所有导航条目都躺在「文章」列表里，几百个网址之后，后台那页会同时混着真文章和网址条目，找东西得靠分类和搜索。
三、跑起来的门槛
| 组件 | 最低 | 推荐 | 备注 |
|---|---|---|---|
| PHP | 7.4 | 8.x | 类型声明与性能都更好 |
| Typecho | 1.2 | 最新稳定版 | 更早的版本没测过 |
| MySQL | 5.7 | 8.0 | TiDB、PlanetScale 这类兼容协议也能跑 |
| Node.js | — | 当前 LTS | 只在改前端、重新构建资源时需要 |
| pnpm | — | — | 装依赖与执行构建脚本 |
Release 包里带的是构建好的静态资源，直接上传到主题目录就能用，不需要在那台服务器上装 Node。只有你要改样式、加组件，才需要在本地起构建环境。这点对虚拟主机用户挺友好。
还有一个初始化行为要提前知道：主题启用或版本变化时，会自动给文章补「浏览量」「点赞」等字段，并记录当前主题版本。这属于「装完自己就改了数据库」，虽然改的是自己的表，但升级前备份数据库这件事不能省。
四、外部依赖：图标、头像、天气
主题默认会调用外部的图标源、头像源和天气接口，三样都能在设置里换。天气这一项作者做了自托管方案：cloudflare-workers-api 部署到 Workers，把返回地址填进「天气 API 地址」即可，不用再依赖作者那台服务器。
这类「默认走公共服务、支持自托管」的处理方式，是长期维护的项目才会想到的细节——大部分个人主题会直接把某个公共接口写死在代码里，接口一挂，首页就空一块。
五、几个实际会踩到的点
第一，导航站的内容量会长得很快。一开始放二十个站点，半年后可能五百个。这时分类结构比主题外观重要得多——先把一级分类定好，别等堆到三百个再回头整理。子分类的「平铺 / 收纳」选择也要提前想清楚：平铺看得全但页面很长，收纳整洁但多一次点击。
第二，图标是个体力活。每个站点都要一张图标 URL，要么自己抓 favicon，要么用第三方图标源。后者方便，但对方挂了你的页面就一片空白；前者麻烦，但可控。设置里能换图标源，说明作者也知道这事没有标准答案。
第三，自定义代码是双刃剑。「自定义头部代码」和「自定义底部代码」会原样输出到页面，塞统计脚本、验证 meta 很方便，但也意味着贴进去什么就执行什么。文档里那句「仅建议放置可信的统计、验证或少量样式脚本」，不是客套话。
第四，GPL-3.0 是有约束力的。改完在自己的站上用，没问题；但如果你基于它做一个分发版本、或者做成付费主题卖，GPL 要求你同样开源。这和那些「随便用」的个人主题不是一回事，商用前最好读一遍协议。
六、适合谁
如果你手上有 Typecho、想搭一个自己的导航首页（收藏夹、行业站点合集、团队内部工具入口），又不想为这件事再维护一套 CMS，ITEM 大概是目前最省事的选择：数据是文章，管理用原生后台，前端是一套完整的仪表盘模板，还带搜索聚合、天气和工具宫格。它做的是「导航站」这件事，而不是「博客加个链接页」，这个定位差别在长期使用中会越来越明显。
反过来说，如果你只是想在博客侧边栏加十几个友链，那用它属于杀鸡用牛刀——主题接管的是整个站点首页结构，装了它，原来的博客形态就变了。
本文整理自公开资料并重写：项目仓库 README 与 Wiki（环境与兼容性、版本说明、配置说明三页：PHP / Typecho / MySQL 版本要求、三类内容与自定义字段、分类与图标映射规则、搜索与工具直达的 JSON 配置、天气接口自托管方式、自定义代码说明）、Releases 页（v2.1.0 / v2.0.1 / v2.0.0 / v1.3.0 / v1.2.4 及发布时间）、仓库元信息（星标、fork、issue、许可证、建仓与最近提交时间），以及示例站首页的实际渲染结果。仓库与站点数据截至 2026 年 11 月，具体以 GitHub 页面为准。配图两张分别取自仓库自带效果图与示例站实际截图（仅统一格式、去元数据与压缩，未改动像素，页面中出现的第三方站点名称属示例站内容），一张为依据 Wiki 自绘的数据模型图。页脚署名、Star 入口、捐赠与社群信息未收录。
本文整理自公开资料并做重写，原始出处：https://github.com/fordes123/ITEM。文中配图已去除站点叠加水印与推广信息；版权归原作者所有。