Obsidian - 使用 Share Note 分享笔记并自部署

作者:LinXunFeng日期:2026/6/22

欢迎关注微信公众号:FSA全栈行动 👋

一、前言

最近在整理 Obsidian 笔记时,经常会遇到一个小需求:想把某一篇笔记快速分享给别人,但又不想为了它单独搭建博客、导出 PDF 或复制到其它平台

如果只是分享纯文本,复制粘贴当然可以。但 Obsidian 笔记里往往会有这些内容:

  • 图片附件
  • 代码块
  • Callout 提示块
  • 标签、任务列表
  • Dataview 查询结果
  • 当前主题样式和自定义 CSS
  • 笔记之间的内部链接

这时候手动搬运就有点麻烦了,格式容易丢,图片也要重新处理。这里介绍一个插件:Share Note

它的目标很直接:Obsidian 里一键把当前笔记发布成网页,并尽量保持和本地笔记一致的显示效果

本文主要介绍两部分:

  • Share Note 的基础使用
  • 为什么以及如何使用 note-sx/server 自部署分享服务

二、Share Note 能做什么

Share Note 是一个 Obsidian 插件,官方仓库地址如下:

它比较吸引我的点主要有几个:

  • 一键分享: 在命令面板执行命令即可发布当前笔记
  • 主题支持: 会上传当前主题、主题配置以及自定义 CSS 片段
  • 内容支持比较完整: 图片、代码块、Callout、任务列表、标签等都能正常展示
  • 支持笔记链接: 如果两个笔记都已经分享,分享页面里的内部链接也可以跳转
  • 默认加密: 笔记正文默认加密,解密密钥放在分享链接的 # 后面

当然,这里也要提前说明一点:Share Note 适合分享笔记,不适合当成网盘使用。官方也说明了,加密只作用于笔记正文,附件并不会加密存储

三、基础使用

1、安装插件

Obsidian 中进入:

1设置 -> 第三方插件 -> 社区插件市场
2

搜索 Share Note 并安装启用即可。

如果你习惯手动安装,也可以从 GitHub 仓库下载插件文件放到:

1<VAULT_DIR>/.obsidian/plugins/share-note
2

这里的 <VAULT_DIR> 指的是你的 Obsidian 仓库根目录,也就是存放笔记文件的那个文件夹,默认在文稿目录下,如:

1/Users/lxf/Documents/Obsidian\ Vault
2

安装完成后重启 Obsidian 或重新加载插件。

2、分享当前笔记

打开任意一篇笔记,然后通过命令面板(快捷键 Cmd + P)输入:

1Share Note
2

选择 Share Note: Share current note 命令。

也可以点击笔记右上角的 菜单,选择:

1Share note on the web
2

首次分享时,插件会上传当前主题相关资源。后续再分享其它笔记时,会复用之前上传过的主题文件,所以速度会更快一些。

如果你修改了主题、CSS 片段,或者发现网页展示效果没有同步,可以执行:

1Force re-upload of all data for this note
2

这个命令会强制重新上传当前笔记相关数据。

3、复制分享链接

分享成功后,插件会生成一个网页链接。你可以把这个链接发给其他人,对方打开后就能看到这篇笔记。

如果需要重新复制已经分享过的笔记链接,可以执行:

1Copy shared note link
2

需要注意的是,插件会把分享链接写入系统剪贴板,但不会读取剪贴板内容。

四、关于加密

Share Note 默认会对笔记正文进行加密。官方示例里,一个加密分享链接大概长这样:

1https://share.note.sx/4earajc8#PtC3oQDjDQK9VP7fljmQkLBA/rIMb2tbFsGoG44VdFY
2

它可以拆成两部分来看:

1https://share.note.sx/4earajc8
2

这是笔记页面地址。

1#PtC3oQDjDQK9VP7fljmQkLBA/rIMb2tbFsGoG44VdFY
2

这是解密密钥。

也就是说,如果只有前半段地址,服务端或访问者都无法直接看到笔记正文。只有拿到完整链接的人,浏览器才能在本地完成解密并展示内容。

这里有几个常用控制方式:

  • 默认情况:笔记正文加密分享
  • 单篇不加密:在 frontmatter 里添加 share_unencrypted 并勾选
  • 默认不加密时,单篇加密:在 frontmatter 里添加 share_encrypted 并勾选

这里的 frontmatter 指的是笔记最开头用 --- 包起来的元信息区域,也就是给这篇笔记添加一些属性。比如想让某一篇笔记不加密分享,可以在笔记最上方添加:

1---
2share_unencrypted: true
3---
4

如果你使用的是 Obsidian 的属性面板,也可以在笔记顶部添加一个名为 share_unencrypted 的复选框属性,然后把它勾选上。

不过再强调一下:附件不在正文加密范围内。如果笔记里包含敏感图片、文件、截图,请不要直接分享,或者先自行脱敏。

五、为什么要自部署

默认情况下,Share Note 会使用官方服务:

1https://api.note.sx
2

对于普通分享来说,这已经足够方便。但如果使用频率比较高,或者笔记内容对可控性要求更高,我会更倾向于自部署一份服务。

主要原因有几个:

  • 域名可控: 分享链接可以使用自己的域名,长期维护更稳定
  • 数据可控: 笔记页面、附件和数据库都落在自己的服务器上
  • 权限可控: 可以关闭新用户注册,只给自己生成 API Key 使用
  • 容量可控: 可以根据自己的服务器和存储情况调整上传大小限制
  • 服务可控: 不依赖公共服务状态,后续迁移、备份也更主动

当然,自部署也不是没有成本。你需要自己准备服务器、域名、HTTPS、备份和安全策略。如果只是偶尔分享几篇公开笔记,直接使用官方服务会更省心。

六、自部署 note-sx/server

Share Note 的后端服务也开源了,仓库地址如下:

官方提供了 Docker 部署方式,整体流程比较简单。

1、准备目录

先在服务器上准备一个目录:

1mkdir -p ~/notesx-server
2cd ~/notesx-server
3

目录里后续会放三个核心内容:

1notesx-server
2├── docker-compose.yml
3├── .env
4├── db
5└── userfiles
6
  • docker-compose.yml:服务编排配置
  • .env:服务运行参数
  • db:服务数据库目录
  • userfiles:用户上传文件目录

2、编写 docker-compose.yml

创建 docker-compose.yml

1services:
2  notesx-server:
3    image: ghcr.io/note-sx/server:latest
4    container_name: notesx-server
5    restart: always
6    ports:
7      - "3000:3000"
8    env_file:
9      - ".env"
10    volumes:
11      - ./db:/notesx/db:Z
12      - ./userfiles:/notesx/userfiles:Z
13    healthcheck:
14      test: (wget -qO - http://localhost:3000/v1/ping | grep -q ok) || exit 1
15      interval: 30s
16      timeout: 5s
17      retries: 2
18      start_period: 10s
19

服务默认会监听容器内的 3000 端口,这里映射到宿主机的 3000 端口。

如果你的服务器前面还有 NginxCaddy 或其它反向代理,只要把外部域名代理到:

1http://127.0.0.1:3000
2

即可。

3、编写 .env

创建 .env

1BASE_WEB_URL=https://note.example.com
2CLOUDFLARE_TURNSTILE_KEY=
3CLOUDFLARE_TURNSTILE_SECRET=
4CLOUDFLARE_ZONE_ID=
5CLOUDFLARE_API_KEY=
6HASH_SALT=please-change-this-to-a-random-string
7FOLDER_PREFIX=0
8MAXIMUM_UPLOAD_SIZE_MB=5
9ALLOW_NEW_USERS=true
10

几个需要重点关注的配置如下:

配置说明
BASE_WEB_URL对外访问的服务地址,比如 https://note.example.com
HASH_SALT随机字符串,建议使用足够长的随机值
MAXIMUM_UPLOAD_SIZE_MB单次上传大小限制,默认示例是 5
FOLDER_PREFIX是否按文件名前 N 位拆分目录,可选 0、1、2
ALLOW_NEW_USERS是否允许新用户注册
CLOUDFLARE_TURNSTILE_KEY如需注册验证码,可配置 Cloudflare Turnstile
CLOUDFLARE_ZONE_ID如前面接入 Cloudflare,可按需配置

如果只是自己使用,建议首次完成账号/API Key 准备后,把:

1ALLOW_NEW_USERS=false
2

这样可以避免其它人注册新用户。已有用户仍然可以生成新的 API Key。

这里需要注意:ALLOW_NEW_USERS 是通过 .env 注入到容器里的环境变量,修改 .env 后需要让容器重新创建,配置才会真正生效。可以执行:

1docker-compose up -d --force-recreate
2

如果你使用的是新版 Docker Compose 命令,也可以写成:

1docker compose up -d --force-recreate
2

不建议只执行 docker-compose restart,因为它通常只是重启已有容器,不会重新读取并应用新的环境变量。上面的命令会复用 dbuserfiles 挂载目录,不会清空已分享的数据。

4、启动服务

执行:

1docker-compose up -d
2

启动后可以查看容器状态:

1docker-compose ps
2

也可以访问健康检查接口:

1curl http://127.0.0.1:3000/v1/ping
2

正常情况下会返回包含 ok 的结果。

5、配置反向代理

如果使用 Nginx,可以参考下面的配置:

1server {
2    listen 80;
3    server_name note.example.com;
4
5    location / {
6        proxy_pass http://127.0.0.1:3000;
7        proxy_set_header Host $host;
8        proxy_set_header X-Real-IP $remote_addr;
9        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
10        proxy_set_header X-Forwarded-Proto $scheme;
11    }
12}
13

生产环境建议再配上 HTTPS。如果你使用的是 Caddy,配置会更简单:

1note.example.com {
2    reverse_proxy 127.0.0.1:3000
3}
4

七、让 Obsidian 使用自部署服务

服务部署完成后,还需要让 Share Note 插件请求自己的服务。

根据 note-sx/server 的说明,需要修改当前仓库里的插件配置文件:

1<VAULT_DIR>/.obsidian/plugins/share-note/data.json
2

打开后找到默认服务地址相关字段,通常能看到类似下面这样的地址:

1https://api.note.sx
2

把它改成自己的服务器地址即可:

1https://note.example.com
2

实际字段名请以你本地 data.json 里的已有内容为准,不要把其它配置删掉,只替换服务地址即可。

当然,也可以在设置页中找到第三方插件 Share Note,打开 Show advanced options, 修改 Server URL

修改完成后,重新加载插件或重启 Obsidian,让配置生效。

这里还有一个小细节:这个 data.json 位于 .obsidian 目录下,如果你使用 Obsidian SyncGit 或其它同步方案,它会跟随你的普通同步流程同步到其它设备。也就是说,多设备场景下不需要每台机器都手动配置一遍。

八、验证流程

最后可以按下面这个流程验证一下:

  1. Obsidian 新建一篇测试笔记
  2. 插入一张图片、一个代码块
  3. 执行命令 Share Note: Share current note
  4. 打开生成的分享链接
  5. 确认页面域名是自己的 BASE_WEB_URL
  6. 确认图片、代码块、主题样式都能正常展示
  7. 修改笔记内容后重新分享,确认页面内容会更新

如果访问失败,可以优先检查这几个地方:

  • docker-compose ps 中容器是否正常运行
  • curl http://127.0.0.1:3000/v1/ping 是否返回 ok
  • 反向代理是否正确转发到 3000 端口
  • BASE_WEB_URL 是否和外部访问域名一致
  • data.json 中插件服务地址是否已经改成自部署地址
  • 修改配置后是否已经重启 Obsidian 或重新加载插件

九、最后

整体体验下来,Share Note 比较适合这类场景:

  • 临时分享一篇格式完整的 Obsidian 笔记
  • 给同事或朋友发一份技术记录、排查过程、会议纪要
  • 不想为单篇内容单独搭建博客,但又希望展示效果比纯文本更好
  • 对分享域名、数据落点、注册权限有要求,所以选择自部署

如果你只是偶尔分享公开内容,直接使用官方服务就很方便;如果你和我一样,更在意长期可控、域名统一和数据落点,那就可以考虑把 note-sx/server 部署到自己的服务器上。

本篇到此结束,希望对你有帮助~

如果文章对您有所帮助, 请不吝点击关注一下我的微信公众号:FSA全栈行动, 这将是对我最大的激励. 公众号不仅有 iOS 技术,还有 AndroidFlutterPython 等文章, 可能有你想要了解的技能知识点哦~


Obsidian - 使用 Share Note 分享笔记并自部署》 是转载文章,点击查看原文


相关推荐


RabbitMQ 从入门到精通:Spring Boot 实战三部曲(一)—— 基础核心与快速上手
绝知此事2026/6/14

RabbitMQ 从入门到精通:Spring Boot 实战三部曲(一)—— 基础核心与快速上手 专题导读:本系列共三篇,从基础到高级,带你系统掌握 RabbitMQ 在 Spring Boot 项目中的实战应用。 第一篇:基础核心与快速上手(本文)第二篇:进阶特性与可靠性保障第三篇:高级应用与性能优化 📖 前言 在当今的分布式系统中,消息队列已成为不可或缺的基础设施。RabbitMQ 作为最流行的消息中间件之一,以其可靠性、灵活性和易用性著称。 本文将从 RabbitMQ 的基础概念出


iOS、Android、Flutter 2026 流行框架对比
王若风2026/6/7

参考文章:iOS、Android、Flutter 流行框架对比(原始链接) 我把我 2 年前的一篇博客文章进行了一次“重写”,于是有了这篇。 原文的选题很实用,结构也很清晰:按布局、网络请求、图片加载三个维度,把 iOS、Android、Flutter 常见框架放在一起横向看。 帮助移动端开发洞察各端核心框架的流行趋势,提供洞察和选项参考。 但原文的数据,放到 2026 年 6 月再看,已经有点过期了。 比如 Jetpack Compose 已经不是“新趋势”,而是 Android 新项目的


数据采集卡技术全解:从硬件架构到行业应用
zlinear数据采集卡2026/5/31

目录 数据采集卡技术全解:从硬件架构到行业应用 一、数据采集卡基础概念与分类体系 1.1 核心概念:连接物理世界与数字世界的桥梁 1.2 数据采集卡的核心功能构成 1.3 与传统测量仪器的本质区别 1.4 多维度的分类体系 1.4.1 按核心性能(采样率)分类 1.4.2 按总线接口类型分类 1.4.3 按功能与应用分类 章节小结 二、硬件架构深度解析 2.1 整体架构视图:从信号入口到数据出口 2.2 模拟前端:信号的“守门人”与“化妆师” 2.3 数据转换核心:A


技术选型决策树:什么团队、什么项目该选什么框架 | 跨平台框架深度对决(4)
陆业聪2026/5/10

跨平台框架深度对决系列 · 第4/4篇(完结篇) Flutter vs KMP vs KuiKly vs RN,谁是2026年的最优解 第1篇:跨平台框架全景图——Flutter/KMP/KuiKly/RN的2026年格局 第2篇:渲染引擎与性能拆解——自绘vs原生渲染vs Bridge的终极对决 第3篇:架构哲学与工程化——从开发体验到CI/CD的全维度对比 第4篇:技术选型决策树——什么团队、什么项目该选什么框架(本篇 · 完结) 上个月,有三个不同的朋友分别找我聊跨平台选型。 第一个是创业


RAG 系列(二):用 LangChain 搭建你的第一个 RAG Pipeline
冬奇Lab2026/4/30

从 100 行代码到生产级 Pipeline 上一篇我们用手写 Python 搭了一个最小 RAG,100 行代码跑通了核心逻辑。但如果你想把那套代码搬到生产环境,很快就会撞上一堵墙。 要加载 PDF? 你需要 PyPDF2 或 pdfplumber,然后发现表格、页眉页脚的解析是一场噩梦。 要切分文本? 你那个朴素的 text.split("\n\n") 会把句子拦腰截断、破坏代码块,或者切出超长的块直接把 Token 上限撑爆。 想换个向量数据库? 祝你下午愉快——每个数据库的 API 都不


告别 jq 噩梦!这款 JSON 神器 fx 让你在终端体验“丝滑”的数据操作
GetcharZp2026/4/21

还在为复杂的 jq 语法抓狂?antonmedv/fx 带着交互式 TUI 和纯正 JavaScript 语法来了!JSON 调试、过滤、转换,一个工具全搞定。 在程序员的日常摸鱼……哦不,日常开发中,JSON 绝对是出现频率最高的朋友。 不管是调用后端接口、查看 K8s 配置,还是分析爬虫数据,面对满屏密密麻麻、甚至没有缩进的原始 JSON 字符串,我们的第一反应通常是: 打开浏览器,搜索“JSON 在线格式化”。 把数据粘进去,点一下“美化”。 忍受网页弹窗广告,或者担心敏感数据泄露。


实测对比:哪款开源 Kubernetes MySQL Operator 最值得用?(2026 深度评测)
小猿姐2026/4/13

本文基于作者在 AWS EKS 上对四款 MySQL Operator 的真实部署与测试,覆盖集群搭建、高可用切换、弹性扩缩容、动态参数、TLS 等维度,适合正在评估 MySQL Kubernetes 方案的工程师参考。 一、为什么要做这次对比测试? 过去两年,越来越多的团队开始将 MySQL 从虚拟机迁移到 Kubernetes。驱动力很直接:统一的基础设施管控、更快的弹性扩容、以及 GitOps 风格的声明式运维。 但随之而来的问题是:MySQL Operator 怎么选? 我们决定不依赖


Claude Code 的权限系统是如何工作的
candyTong2026/4/5

在 agent runtime 的实现里,权限从来不是外围配置项,而是执行系统的一部分。只要模型开始改文件、跑命令、调用外部工具,系统就必须回答一个核心问题:这一步是否允许执行,以及这个判断应该在执行链路的哪个位置完成。 Claude Code 的权限系统很适合作为分析样本。它不是在工具外面额外包一层确认框,而是把权限判断直接嵌入工具调用链路,让一次工具调用从发起到落地,始终伴随一套可组合、可回写的运行时裁决。 文章从一个常见工作场景切入,分析权限系统实际解决的问题、内部层次划分,以及这些设计对


阿里云服务迁移实战(二)——网关迁移与前后端分离配置
KD2026/3/27

一、背景 由于业务原因,需要把服务器从外部阿里云账号迁移到阿里云账号 原阿里云是在服务器上部署Nginx做网关,迁移后改用阿里云CLB 同时对前后端分离逻辑做梳理,调整为更高效合理的配置 二、Nginx迁移至CLB 1.采用阿里云CLB原因 高可用性:会自动做健康检查,如果服务出现问题,会自动做流量切换 自动化管理:部署后阿里云会处理CLB的监控、更新和运维,无需手动维护 2.迁移前 迁移前Nginx部署在一台ECS服务器上 3.迁移后 迁移后单独部署负载均衡CLB 4.迁移


我让 AI 操作网页之后,开始不想点按钮了
糟糕好吃2026/3/19

每天在后台系统填表单、在电商网站筛商品、在管理后台点来点去……如果有一天,你只需要说一句话,AI 就能替你干完这些活,你会不会觉得:我的双手终于可以解放了? 说实话,我第一次看到阿里开源的 PageAgent 时,脑子里蹦出的就是上面那句话。这是一个能听懂人话、然后直接帮你操作网页的小工具——不需要写脚本,不需要装插件(甚至可以用书签),只需要一行代码,或者一句话。 它让我突然意识到:我们和网页的交互方式,可能正在迎来一次真正的变革。 一、体验下三个让你“哇塞”的场景 场景一:后台系统创建用

首页编辑器站点地图

本站内容在 CC BY-SA 4.0 协议下发布

Copyright © 2026 聚合阅读