Misskey 2026.10.1 介绍与选型指南

目标：面向「准备自托管联邦社交节点、在 Mastodon 与功能丰富的日系服务端 Misskey 之间做选择」的读者，讲清 Misskey 是什么、版本节奏如何、架构与功能边界在哪，并与 Mastodon、Akkoma、Pleroma、GoToSocial、Sharkey 做量化选型对比。本文为认知溯源篇，全部信息来自官方 GitHub 仓库、官方管理文档站 misskey-hub.net 与 Releases API 的联网取证，查询日期统一为 2026-11-02，未做本地实测；部署实测与命令回显见本专栏部署篇。

一、环境信息

本章说明本文的信息检索口径，供读者复核每一条结论的来源。

• 组件与版本：Misskey 2026.10.1（查询当日 GitHub Releases 最新稳定版，发布于 2026-10-23T23:34:05Z，来源：https://api.github.com/repos/misskey-dev/misskey/releases?per_page=100，查询日期 2026-11-02）。版本号采用 CalVer（年.月.修订）而非语义化版本：2026.10.1 即 2026 年 10 月主线的首个修订版。
• 官方代码仓库：https://github.com/misskey-dev/misskey（created 2016-12-25；stars 11369、forks 1640、contributors 307、主语言 TypeScript、许可 AGPL-3.0，来源：GitHub 仓库 API，查询日期 2026-11-02）。
• 官方站点与管理文档：https://misskey-hub.net（README 首页 "Learn more" 指向该站；管理员安装指南位于 https://misskey-hub.net/docs/for-admin/install/guides/，查询日期 2026-11-02）。
• 实例目录：https://misskey-hub.net/servers/（官方 "find an instance" 入口，README 徽章直链）。
• 本文性质：A1 认知篇，仅联网溯源，所有数据标注来源与查询日期；环境实测（部署、命令回显、参数生效验证）见本专栏各实测篇。

版本节奏实查（GitHub Releases 前 100 条全量清点，查询日期 2026-11-02）：近 12 个月共 18 个稳定版（2025-11-28 的 2025.11.1 → 2026-10-23 的 2026.10.1），呈「按月主线 + 随时补丁」节奏；稳定版之间穿插 alpha/beta/rc 预发布通道（2026.10.2-alpha.0 已于 2026-10-31 发布）。近几个稳定版：

💡 解读：CalVer 下「月份缺号」不等于停更，而是当月未出主线；升级基线应取上一个不带 alpha/beta/rc 后缀的稳定版。

二、软件概述

本章回答「Misskey 是什么、从哪来、由谁维护」三个基本问题。

Misskey 是一个自由开源的联邦式（decentralized）社交媒体平台，官方 README 自我表述为 "an open source, federated social media platform that's free forever"。它由日本开发者 syuilo 于 2016 年创建（README 页脚仍挂 patreon.com/syuilo 创始人捐赠入口），基于 W3C ActivityPub 标准实现跨实例互关互访，与 Mastodon、Pleroma 等软件互通（来源：README 与 misskey-hub《Getting Started》文档，查询日期 2026-11-02）。Misskey 是 MFM（Misskey Flavored Markdown）富文本语法的原产地——Akkoma/Pleroma 的「Misskey 风味 Markdown」即其方言（来源：Akkoma 官方站点，见 《Akkoma 3.20.1 介绍与选型指南》 第二章）。

核心事实速览（均标注来源，查询日期 2026-11-02）：

💡 说明：README 的 Thanks 段集中展示了「商业工具链赞助 + 个人 Patreon」的组合——这是无单一商业公司背书项目的典型维护模型；307 名贡献者（GitHub API 实查）支撑了 12 个月 18 个稳定版的高频节奏，选型时应把「升级频率」本身当作运维成本项。

三、核心架构

本章拆解 Misskey 单实例的内部组成与联邦协议层，这是理解其资源占用与运维复杂度的基础。

3.1 前后端同仓：TypeScript monorepo

Misskey 是单仓库 monorepo：后端（packages/backend，NestJS 依赖注入容器 + TypeORM 数据层）与前端（Vue 技术栈的 Web 客户端）同仓构建，pnpm workspace 管理。本专栏部署篇实测回显可交叉印证：启动日志逐行输出 Nest 容器初始化序列（[core.nest] InstanceLoader: QueueModule / RepositoryModule / CommandModule / GlobalModule / CoreModule dependencies initialized），数据库结构由 TypeORM 迁移驱动（349 migrations were found in the source code，实测建表 117 张）。

💡 技术拓展：联邦社交服务端的前端形态不止本文所用的「自有 SPA + 自有 API」一种。常见形态对比——

形态	代表实现	取舍
自有 SPA + 自有 API	Misskey	功能表达最强（游戏/页面/云盘全在前端做），但第三方客户端难追平
后端 + 可插拔静态前端	Akkoma/Pleroma	前端可换皮，可装 Mastodon 式多列界面
前后端同仓同部署	Mastodon	Rails 视图 + 打包 JS，客户端靠 Mastodon API 生态
仅 API、界面全靠第三方	GoToSocial	官方无 Web 界面，UI 由客户端生态承担

Misskey 选第一种：离开官方 Web 界面就失去大部分功能，这是它与「客户端生态优先」路线的根本分野。

3.2 进程模型：cluster 多 worker + 进程内作业队列

官方预构建产物的启动命令为 pnpm run migrateandstart（先跑数据库迁移再拉起服务，Dockerfile 实测 CMD）。进程模型是 Node.js cluster：master + clusterLimit 个 worker 进程（配置默认 1），每个 worker 同时处理 HTTP 请求与消费 Redis 作业队列（联邦投递 deliver、收件 inbox 等），没有独立的 Sidekiq 式 worker 服务。实测印证：把 clusterLimit 改为 2 重启后，日志立即从 Starting 1 worker... 变为 Starting 2 workers...；配置模板中每 worker 的作业并发与限速参数（deliverJobConcurrency、inboxJobPerSec、deliverJobMaxAttempts 等）均按 worker 维度生效。

💡 技术拓展：Node 系社交服务的并发模型不止 cluster 一种。常见选择——

模型	代表	特点
cluster 多 worker（本文方案）	Misskey clusterLimit	单机吃满多核，部署面只有一个服务
Web 与 worker 进程分离	Mastodon（Puma + Sidekiq + Streaming）	队列处理独立扩缩，运维对象多
BEAM 单进程 Actor	Akkoma/Pleroma	无 worker 数量概念，进程内并发
单二进制内 goroutine	GoToSocial	Go 运行时调度，依赖最少

本文实测采用 cluster 模型：扩容只动 clusterLimit 一个参数，代价是队列消费与 Web 共享同一进程池，无法像 Sidekiq 那样独立伸缩。

3.3 联邦协议与 API 层

• ActivityPub：跨实例关注、发帖投递（Create/Announce/Like/Follow）主协议；WebFinger：@用户名@域名 的 actor 发现解析；misskey-hub《Getting Started》明确「Misskey 的联邦基于 ActivityPub 开放标准，与 Mastodon、Pleroma 等软件兼容」（查询日期 2026-11-02）。
• API 为自有 REST、一律 POST：本专栏实测 GET /api/meta 返回 405（access 日志实录 GET /api/meta 405），POST /api/meta {} 才返回 JSON（含 version: "2026.10.1"、maxNoteTextLength: 3000、disableRegistration: true、maxFileSize: 104857600）——「全 POST」是与 Mastodon RESTful 风格最大的 API 认知差异。
• 认证与引导：口令登录走 /api/signin-flow（旧 /api/signin 端点实测已 404 移除）；全新空实例（meta.rootUserId == null）可经 /api/admin/accounts/create 免认证引导首个管理员账号（本专栏部署篇实测成功并签发了 API token）。
• 客户端生态：第三方客户端通过 Misskey 的 Mastodon 兼容端点接入，覆盖面为子集；日常使用以官方 Web 界面为主。

💡 技术拓展：Misskey 的对象 ID 生成方式可配置且初始化后不可更改（配置模板默认 aidx）。可选方案对比——

方式	特点	精度
aid	短 ID、可排序	毫秒
aidx（默认，本文实测）	aid 改进版	毫秒
meid	类 MongoDB ObjectID	毫秒
ulid	标准 ULID	毫秒
objectid	仅为向后兼容保留	—

配置模板原文警告："ONCE YOU HAVE STARTED THE INSTANCE, DO NOT CHANGE THE ID SETTINGS AFTER THAT!"——ID 方式与实例 URL 同属「一次定型」项。

3.4 存储与检索组件

• PostgreSQL：全部结构化数据（实测 PostgreSQL 18.6、117 张业务表），用户、帖子、云盘、角色、审核、游戏数据同库；
• Redis：作业队列 / pubsub / 时间线缓存（实测 redis_version:7.4.12、redis_mode:standalone，键空间含 queue:* 与 list:userTimeline:*）；配置模板还支持为 pubsub、jobQueue、timelines、reactions 各拆独立 Redis 实例（redisForPubsub 等段，默认注释）；
• 附件存储：默认本地磁盘目录（产物内以 UID/GID 991 运行，本专栏部署篇实测目录属主校准），可切 S3 兼容对象存储（经管理面板配置，来源：misskey-hub 管理文档口径）；
• 错误追踪与翻译：Sentry 前后端双端集成（配置模板 sentryForBackend/sentryForFrontend 段）、DeepL 机器翻译（proxyBypassHosts 默认白名单含 api.deepl.com）。

💡 技术拓展：全文搜索引擎三选一（配置模板 fulltextSearch.provider）——

Provider	额外依赖	特点
sqlLike（默认，本文实测）	无	PostgreSQL 标准 LIKE 查询，零扩展成本
sqlPgroonga	pgroonga 扩展 + 手工建索引	词法级检索，需 DBA 介入
meilisearch	独立 Meilisearch 服务	专用搜索引擎，体验最好、部署成本最高

本文实测部署用默认 sqlLike（启动日志实录 [SearchService] -- Provider: sqlLike）。

四、功能特性

本章的「功能地图」直接取自实测数据库的 117 张业务表名（查询日期 2026-11-02），比宣传语更可靠：note/note_reaction（帖子与 emoji 回应）、channel/channel_following（频道）、user_list（列表）、antenna（天线）、clip（剪辑收藏）、page（自定义页面）、flash（可玩小应用）、gallery_post（画廊）、chat_room/chat_message（群聊室）、messaging_message（一对一私信）、drive_file/drive_folder（云盘）、role_assignment（自定义角色）、abuse_user_report/moderation_log（举报与审核日志）、registration_ticket（邀请票）、webhook（出站钩子）、announcement（公告）、reversi_game/bubble_game_record（内置双游戏）、user_security_key（WebAuthn 二步验证）、registry_item（客户端配置同步）、sw_subscription（推送订阅）。

• 表达层：MFM 富文本（实测 maxNoteTextLength: 3000）、自定义 emoji、emoji 回应、转发/引用转发、内容隐藏（CW）、多级可见性（实测 /api/meta 的 policies 段含 canPublicNote、mentionLimit: 20 等）；
• 社区层：频道、天线、列表、剪辑、群组；
• 玩法层：内置黑白棋（Reversi）与泡泡龙（Bubble）游戏（实测表）、page 自定义页面、flash 小应用、gallery 图集；
• 治理层：角色体系、邀请票注册（实测 disableRegistration: true 默认关闭注册）、举报处理、审核日志、公告；
• 集成层：Webhook、Sentry、DeepL 翻译、媒体代理（mediaProxy）、外链 URL 预览。

💡 说明：与 Mastodon 的「短内容时间线 + 治理」主轴相比，Misskey 的功能面接近「社交 + 内容平台」全家桶；代价是功能演进高频（12 个月 18 个稳定版），每次升级前需要通读 CHANGELOG（官方安装文档的 warning 原文，见第五章）。

五、快速开始（最小可用骨架）

官方管理文档给出多条安装路线（misskey-hub《Create your own Misskey instance》：Docker、Bash 脚本、手动、Kubernetes/TrueNAS、YunoHost，查询日期 2026-11-02）。其中 Docker Compose 路线的官方步骤（来源：misskey-hub 安装指南专页，查询日期 2026-11-02）：

git clone -b master https://github.com/misskey-dev/misskey.git
cd misskey
cp .config/docker_example.yml .config/default.yml
cp .config/docker_example.env .config/docker.env
cp ./docker-compose.yml.example ./docker-compose.yml
docker compose build
docker compose run --rm web pnpm run init
docker compose up -d

官方主线是源码构建路线：docker compose build 从仓库源码构建应用，pnpm run init 完成配置编译与数据库初始化（迁移建表）。

⚠️ 制品事实（本专栏实查，2026-11-02）：仓库根目录没有现成的 docker-compose.yml（直接访问返回 404），编排示例实为 compose_example.yml（其应用服务用 build: . 源码构建）；官方同时发布带版本号的预构建产物 misskey/misskey:2026.10.1（实测 2.66GB），可跳过源码构建直接编排。本专栏部署篇实测「预构建产物 + web/db/redis 三服务编排」路线，并完整记录了国内网络环境获取该产物的排障链。

完整可复现的部署（配置文件逐项讲解、引导管理员账号、健康检查验证）见 《Misskey 2026.10.1 Docker Compose 部署指南》；参数生效实测见 《Misskey 2026.10.1 配置参数详解》，命令行工具取证见 《Misskey 2026.10.1 常用 CLI 命令与工具详解》。

六、适用场景与限制

本章给出「什么团队该选/不该选 Misskey」的边界判断。

适用场景：

• 强表达社区/日系时间线用户：MFM 原产地，emoji 回应、频道、游戏、自定义页面一应俱全，「功能花哨」是其产品本色；
• 功能全家桶单实例：一套 Misskey 同时覆盖时间线 + 云盘 + 群聊 + 论坛式页面 + 小游戏，省去多服务拼装；
• 中小规模私密/半开放社区：默认关闭注册 + 邀请票 + 角色/审核工具（实测表齐全），适合先内后放；
• 中日文语言环境：Crowdin 多语言基础设施在位（README Thanks 段），管理文档有中文页。

限制（自托管视角，来源官方配置模板、安装文档与本专栏实测，查询日期 2026-11-02）：

• 资源与依赖档位偏重：TypeScript 全栈 + PostgreSQL/Redis 双必需依赖，预构建产物实测 2.66GB；与 Akkoma/GoToSocial 的「单依赖」路线相比部署基线高；
• 升级高频：12 个月 18 个稳定版，TypeORM 迁移随版本追加（实测 349 个迁移文件），官方安装文档 warning 原文要求升级前必读 release notes（"When updating, be sure to check the release notes"）；
• 一次定型项多：实例 URL 与 ID 生成方式在配置模板中均带 "DO NOT CHANGE" 原文警告，域名与初始化参数必须一次规划到位；
• API 自成体系：全 POST 自有 API，Mastodon 客户端生态只覆盖子集，移动端体验主要依赖官方 Web/渐进式界面；
• 注册默认关闭：实测 disableRegistration: true——部署完成后普通用户无法自助注册，需管理员开放或发放邀请票（实测空请求打 /api/signup 返回 400，该旧端点已不是可用入口）。

七、同类选型对比

本章把 Misskey 与联邦宇宙另外五个主流自托管服务端做量化对比。口径说明：Misskey 列数据查询日期 2026-11-02（GitHub API + 官方配置模板 + 本专栏实测）；Mastodon 列沿用本平台 《Mastodon 4.7.3 介绍与选型指南》 第七章的官方检索口径（查询日期 2026-10-26）；Akkoma 列沿用 《Akkoma 3.20.1 介绍与选型指南》 第七章（查询日期 2026-11-02）；GoToSocial 与 Sharkey/Firefish 的 GitHub API 本次返回 404/限流，星数等量化指标只能定性描述。

关键差异与选型建议：

• 要「功能全家桶 + 强表达」且接受重栈高频 → Misskey：一套服务覆盖时间线/云盘/群聊/页面/游戏，MFM 生态原产地；代价是双必需依赖、12 个月 18 版的升级节奏、自有 API；
• 要「稳、客户端生态全、可运营大社区」→ Mastodon：50k+ 星、治理与扩容文档最体系化；功能表达保守，栈同样重；
• 小机器 + Mastodon 客户端兼容 → Akkoma：最低依赖档（仅 PostgreSQL），MFM 方言补齐表达；详见 《Akkoma 3.20.1 介绍与选型指南》 第七章；
• 认同 Misskey 但对上游节奏/治理有诉求 → Sharkey/Firefish 分支：功能同源，差异在社区治理与取舍；本次 GitHub API 404/限流拿不到量化指标，选型前建议自行复核仓库现状；
• 只要一个省心的 ActivityPub 端点 → GoToSocial：单二进制最省，但无官方 Web 界面且处 Beta。

💡 说明：上表仅对 GitHub 系（Misskey/Mastodon）保留星数锚点（11369★ vs 50462★，查询日期 2026-11-02）；Akkoma 主仓在自托管 Gitea、GoToSocial 在 Codeberg，热度指标不可直接横比，活跃度请各自以发布节奏与实例目录复核。

八、参考链接

• 官方仓库：https://github.com/misskey-dev/misskey（README、.config/docker_example.yml、compose_example.yml 为本文架构与路线依据）
• 官方 Releases API：https://api.github.com/repos/misskey-dev/misskey/releases?per_page=100（版本节奏数据来源）
• 官方站点与管理文档：https://misskey-hub.net/（/docs/for-admin/install/guides/ 安装路线；/docs/getting-started/ 联邦概念）
• 实例目录：https://misskey-hub.net/servers/
• CHANGELOG：https://github.com/misskey-dev/misskey/blob/master/CHANGELOG.md（官方要求升级前必读）
• 社区：Discord https://discord.gg/Wp8gVStHW3；创始人捐赠 https://www.patreon.com/syuilo
• ActivityPub 标准：https://www.w3.org/TR/activitypub/
• 同生态对照实测：《Mastodon 4.7.3 介绍与选型指南》、《Akkoma 3.20.1 介绍与选型指南》、《Mastodon 4.7.3 Docker Compose 部署指南》