Page Assist Page Share 功能完全指南聊天分享原理与 Railway / Docker 自托管部署【免费下载链接】page-assistUse your locally running AI models to assist you in your web browsing项目地址: https://gitcode.com/GitHub_Trending/pa/page-assistPage Share 是 Page Assist 浏览器扩展提供的公开聊天分享能力其定位与 ChatGPT 的 Share 功能类似将本地 AI 模型的对话内容生成一个可公开访问的链接分发给任何人查看。本指南以仓库中的 page-share.md及 docs/features/page-share.md为骨架结合设置页面、分享弹窗与 Dexie 本地数据库的源码实现完整讲解 Page Share 的运作机制、默认托管服务器、两种自托管方案Railway 与 Docker以及配置入口的实战细节。读完本文你将掌握如何在隐私优先的前提下搭建自己的分享服务并理解分享链接从生成、保存到删除的完整调用链。一、Page Share 是什么Page Share 是 Page Assist 内置的一项功能允许你把一次聊天对话记录分享到公网供他人通过链接浏览这与 ChatGPT 官方的分享功能体验一致。它默认与互联网交互——即默认情况下分享请求会发送到官方托管的 Page Share 服务器。官方默认服务器的地址作为代码常量固化在扩展中见 src/services/ollama.tsconst DEFAULT_PAGE_SHARE_URL https://pageassist.xyz该常量与getPageShareUrl/setPageShareUrl一起工作src/services/ollama.tsexport const getPageShareUrl async () { const pageShareUrl await storage.get(pageShareUrl) if (!pageShareUrl || pageShareUrl.length 0) { return DEFAULT_PAGE_SHARE_URL } return pageShareUrl } export const setPageShareUrl async (pageShareUrl: string) { await storage.set(pageShareUrl, pageShareUrl) }即当用户没有在设置中配置自定义分享服务器时所有分享请求默认发往pageassist.xyz。隐私考量文档明确指出出于隐私与安全考虑更推荐自托管 Page Share 服务器。原因很直观官方服务器上你的聊天内容会经手第三方托管方自托管后分享数据只存在于你自己的基础设施Railway 项目或 Docker 容器中自托管还能保证服务地址、可用性与数据留存策略完全由你掌控。因此自托管是官方文档推荐的生产级用法下文两种方式任选其一即可。二、自托管方案一Railway 一键部署Railway 是最快的部署路径适合不想接触 Docker 细节的用户。在 Page Share 文档页面中点击Deploy on Railway按钮即可跳转到 Railway 的官方模板页将 page-share-app 的代码直接部署到 Railway 平台无需手动克隆代码或编写配置。部署完成后Railway 会为你的服务分配一个可访问的公网地址形如https://xxx.up.railway.app。将这个地址记录下来稍后在扩展的设置页中填入即可。三、自托管方案二Docker 本地部署Docker 方案把分享服务跑在自己的机器或自有服务器上完全本地化适合对数据主权要求更高的场景。按照文档的步骤操作1. 克隆仓库git clone https://github.com/n4ze3m/page-share-app.git cd page-share-apppage-share-app 是独立的分享服务端项目与 Page Assist 浏览器扩展解耦扩展负责把聊天内容 POST 给该服务该服务负责存储并渲染公开分享页面。2. 启动服务器docker-compose updocker-compose up会读取仓库内的docker-compose.yml拉起服务端依赖Web 服务、数据库等。首次运行会自动拉取镜像之后服务便持续监听。3. 打开应用浏览器访问http://localhost:3000看到页面正常响应即代表服务已就绪。如果你的部署环境如云服务器需要公网访问可在防火墙或反向代理层把 3000 端口暴露出去同时建议配置 HTTPS。四、在扩展设置页中接入自托管服务无论采用哪种自托管方式部署完成后都需要在 Page Assist 中把分享服务器地址切换为你自己的服务。设置入口位于扩展的设置页面对应组件 src/components/Option/Share/index.tsx页面标题为Manage Share管理分享。该设置页的核心逻辑src/components/Option/Share/index.tsxconst { status, data } useQuery({ queryKey: [fetchShareInfo], queryFn: async () { const [url, shares] await Promise.all([ getPageShareUrl(), getAllWebshares() ]) return { url, shares } } }) const onSubmit async (values: { url: string }) { if (shareModeEnabled) { const isOk await verifyPageShareURL(values.url) if (isOk) { await setPageShareUrl(values.url) } } else { await setPageShareUrl(values.url) } }页面加载时并行读取两样东西当前配置的分享服务器 URL来自pageShareUrl存储项以及本地数据库中已创建的所有分享记录getAllWebshares。URL 校验机制设置页有一个Share Mode分享模式开关src/components/Option/Share/index.tsx通过shareMode存储项控制开启 Share Mode保存 URL 前会先调用verifyPageShareURL校验服务端是否可用关闭 Share Mode直接保存不做校验。校验实现位于 src/utils/verify-page-share.tsexport const verifyPageShareURL async (url: string) { const res await fetcher(${cleanUrl(url)}/api/v1/ping) if (!res.ok) { throw new Error(Unable to verify page share) } const data await res.text() return data pong }可见自托管服务必须实现一个健康检查端点GET /api/v1/ping并返回纯文本pong。只有校验通过新的服务器地址才会被写入存储。这里的cleanUrlsrc/libs/clean-url.ts会把 URL 结尾多余的/去掉保证拼接路径时不会出现双斜杠export const cleanUrl (url: string) { if (url.endsWith(/)) { return url.slice(0, -1) } return url }历史分享记录管理设置页下半部分是一张分享记录表格src/components/Option/Share/index.tsx列出每条分享的标题、链接可点击跳转并提供删除按钮。删除操作会先调用服务端删除接口再清理本地记录src/components/Option/Share/index.tsxconst onDelete async ({ api_url, share_id, id }) { const owner_id await getUserId() const res await fetcher(${api_url}/api/v1/share/delete, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ share_id, owner_id }) }) if (!res.ok) throw new Error(Failed to delete share link) await deleteWebshare(id) return ok }即删除走POST /api/v1/share/delete携带share_id与owner_id服务端删除成功后扩展再调用 Dexie 的deleteWebshare移除本地索引。五、分享链接的生成流程源码级原理了解自托管配置后再看扩展端如何把一次聊天变成公开链接。分享入口位于聊天界面右上角更多选项菜单src/components/Layouts/MoreOptions.tsx点击后弹出分享弹窗ShareModalsrc/components/Common/ShareModal.tsx。弹窗表单分享弹窗包含两个必填字段标题title默认取当前聊天的历史标题通过getTitleById(historyId)读取姓名name分享页面中人类消息的显示名。表单下方会实时渲染该次聊天的全部消息预览确认无误后提交。消息重构提交前消息列表会经过reformatMessages重排src/components/Common/ShareModal.tsx每条消息被转换为{ id, name, isBot, message, reasoning_time_taken, search, images, modelName, modelImage, sources }结构。其中机器人消息的模型名会通过removeModelSuffix去掉厂商后缀如accounts/.../models/前缀人类消息则使用表单里填写的姓名。创建分享链接核心请求在onSubmit中发起src/components/Common/ShareModal.tsxconst onSubmit async (values: { title: string; name: string }) { const owner_id await getUserId() const chat reformatMessages(messages, values.name) const title values.title const url await getPageShareUrl() const res await fetcher(${cleanUrl(url)}/api/v1/share/create, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ owner_id, messages: chat, title }) }) if (!res.ok) throw new Error(t(share.notification.failGenerate)) const data await res.json() return { ...data, url: ${cleanUrl(url)}/share/${data.chat_id}, api_url: cleanUrl(url), share_id: data.chat_id } }关键调用链如下getUserId()获取或生成当前用户 ID —— 首次使用时生成形如user_xxxx-xxxx-xxxx-xxxx的随机 ID 并持久化src/db/dexie/helpers.ts向当前配置的分享服务器发送POST /api/v1/share/create请求体为{ owner_id, messages, title }服务端返回chat_id扩展据此拼接出公开访问地址{服务器地址}/share/{chat_id}链接生成后自动复制到剪贴板同时调用saveWebshare把{ title, url, api_url, share_id }存入本地数据库src/components/Common/ShareModal.tsx。本地记录存储分享记录存储在 Dexie 数据库的webshares表中相关方法定义在 src/db/dexie/chat.ts// Webshare Methods async getWebshare(id: string) { return await db.webshares.get(id) } async getAllWebshares(): PromiseWebshare[] { return await db.webshares.orderBy(createdAt).reverse().toArray() } async addWebshare(webshare: Webshare) { await db.webshares.add(webshare) } async deleteWebshare(id: string) { await db.webshares.delete(id) }saveWebsharesrc/db/dexie/helpers.ts会为记录生成唯一 ID 与时间戳按createdAt倒序排列这就是设置页表格中记录越新越靠前的来源。分享记录同样参与 Firefox 数据迁移流程见 src/db/dexie/migration.ts切换存储后端后历史分享记录不会丢失。六、自托管服务端需要提供的 API约定小结综合扩展源码一个可用的 Page Share 服务端至少要实现以下三个接口接口方法用途请求/响应要点/api/v1/pingGET健康检查返回纯文本pong供verifyPageShareURL校验/api/v1/share/createPOST创建分享请求体{ owner_id, messages, title }返回{ chat_id }/api/v1/share/deletePOST删除分享请求体{ share_id, owner_id }成功返回 2xx/share/{chat_id}GET公开访问页浏览器可渲染的公开聊天页面七、总结与部署建议Page Share 让 Page Assist 的本地对话可以像 ChatGPT Share 一样对外传播官方默认服务器开箱即用但涉及隐私敏感内容时应切换为自托管。实践中推荐快速验证先使用默认pageassist.xyz体验完整流程确认分享、查看、删除链路正常日常使用用 Railway 一键模板部署成本低、免运维强隐私场景用 Docker 在自有服务器部署配合反向代理与 HTTPS 加固并开启设置页的 Share Mode 开关让扩展每次保存前校验服务可用性。无论哪种方式配置完成后都可以在设置页的 Manage Share 区域统一管理服务器地址与历史分享记录整个闭环生成 → 存储 → 查看 → 删除均有对应的 设置页组件、分享弹窗、Dexie 数据层 与 校验工具 可查证。【免费下载链接】page-assistUse your locally running AI models to assist you in your web browsing项目地址: https://gitcode.com/GitHub_Trending/pa/page-assist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/16 23:28:42 · 阅读 1.2k Page Assist Page Share 功能完全指南：聊天分享原理与 Railway / Docker 自托管部署
Page Assist Page Share 功能完全指南聊天分享原理与 Railway / Docker 自托管部署【免费下载链接】page-assistUse your locally running AI models to assist you in your web browsing项目地址: https://gitcode.com/GitHub_Trending/pa/page-assistPage Share 是 Page Assist 浏览器扩展提供的公开聊天分享能力其定位与 ChatGPT 的 Share 功能类似将本地 AI 模型的对话内容生成一个可公开访问的链接分发给任何人查看。本指南以仓库中的 page-share.md及 docs/features/page-share.md为骨架结合设置页面、分享弹窗与 Dexie 本地数据库的源码实现完整讲解 Page Share 的运作机制、默认托管服务器、两种自托管方案Railway 与 Docker以及配置入口的实战细节。读完本文你将掌握如何在隐私优先的前提下搭建自己的分享服务并理解分享链接从生成、保存到删除的完整调用链。一、Page Share 是什么Page Share 是 Page Assist 内置的一项功能允许你把一次聊天对话记录分享到公网供他人通过链接浏览这与 ChatGPT 官方的分享功能体验一致。它默认与互联网交互——即默认情况下分享请求会发送到官方托管的 Page Share 服务器。官方默认服务器的地址作为代码常量固化在扩展中见 src/services/ollama.tsconst DEFAULT_PAGE_SHARE_URL https://pageassist.xyz该常量与getPageShareUrl/setPageShareUrl一起工作src/services/ollama.tsexport const getPageShareUrl async () { const pageShareUrl await storage.get(pageShareUrl) if (!pageShareUrl || pageShareUrl.length 0) { return DEFAULT_PAGE_SHARE_URL } return pageShareUrl } export const setPageShareUrl async (pageShareUrl: string) { await storage.set(pageShareUrl, pageShareUrl) }即当用户没有在设置中配置自定义分享服务器时所有分享请求默认发往pageassist.xyz。隐私考量文档明确指出出于隐私与安全考虑更推荐自托管 Page Share 服务器。原因很直观官方服务器上你的聊天内容会经手第三方托管方自托管后分享数据只存在于你自己的基础设施Railway 项目或 Docker 容器中自托管还能保证服务地址、可用性与数据留存策略完全由你掌控。因此自托管是官方文档推荐的生产级用法下文两种方式任选其一即可。二、自托管方案一Railway 一键部署Railway 是最快的部署路径适合不想接触 Docker 细节的用户。在 Page Share 文档页面中点击Deploy on Railway按钮即可跳转到 Railway 的官方模板页将 page-share-app 的代码直接部署到 Railway 平台无需手动克隆代码或编写配置。部署完成后Railway 会为你的服务分配一个可访问的公网地址形如https://xxx.up.railway.app。将这个地址记录下来稍后在扩展的设置页中填入即可。三、自托管方案二Docker 本地部署Docker 方案把分享服务跑在自己的机器或自有服务器上完全本地化适合对数据主权要求更高的场景。按照文档的步骤操作1. 克隆仓库git clone https://github.com/n4ze3m/page-share-app.git cd page-share-apppage-share-app 是独立的分享服务端项目与 Page Assist 浏览器扩展解耦扩展负责把聊天内容 POST 给该服务该服务负责存储并渲染公开分享页面。2. 启动服务器docker-compose updocker-compose up会读取仓库内的docker-compose.yml拉起服务端依赖Web 服务、数据库等。首次运行会自动拉取镜像之后服务便持续监听。3. 打开应用浏览器访问http://localhost:3000看到页面正常响应即代表服务已就绪。如果你的部署环境如云服务器需要公网访问可在防火墙或反向代理层把 3000 端口暴露出去同时建议配置 HTTPS。四、在扩展设置页中接入自托管服务无论采用哪种自托管方式部署完成后都需要在 Page Assist 中把分享服务器地址切换为你自己的服务。设置入口位于扩展的设置页面对应组件 src/components/Option/Share/index.tsx页面标题为Manage Share管理分享。该设置页的核心逻辑src/components/Option/Share/index.tsxconst { status, data } useQuery({ queryKey: [fetchShareInfo], queryFn: async () { const [url, shares] await Promise.all([ getPageShareUrl(), getAllWebshares() ]) return { url, shares } } }) const onSubmit async (values: { url: string }) { if (shareModeEnabled) { const isOk await verifyPageShareURL(values.url) if (isOk) { await setPageShareUrl(values.url) } } else { await setPageShareUrl(values.url) } }页面加载时并行读取两样东西当前配置的分享服务器 URL来自pageShareUrl存储项以及本地数据库中已创建的所有分享记录getAllWebshares。URL 校验机制设置页有一个Share Mode分享模式开关src/components/Option/Share/index.tsx通过shareMode存储项控制开启 Share Mode保存 URL 前会先调用verifyPageShareURL校验服务端是否可用关闭 Share Mode直接保存不做校验。校验实现位于 src/utils/verify-page-share.tsexport const verifyPageShareURL async (url: string) { const res await fetcher(${cleanUrl(url)}/api/v1/ping) if (!res.ok) { throw new Error(Unable to verify page share) } const data await res.text() return data pong }可见自托管服务必须实现一个健康检查端点GET /api/v1/ping并返回纯文本pong。只有校验通过新的服务器地址才会被写入存储。这里的cleanUrlsrc/libs/clean-url.ts会把 URL 结尾多余的/去掉保证拼接路径时不会出现双斜杠export const cleanUrl (url: string) { if (url.endsWith(/)) { return url.slice(0, -1) } return url }历史分享记录管理设置页下半部分是一张分享记录表格src/components/Option/Share/index.tsx列出每条分享的标题、链接可点击跳转并提供删除按钮。删除操作会先调用服务端删除接口再清理本地记录src/components/Option/Share/index.tsxconst onDelete async ({ api_url, share_id, id }) { const owner_id await getUserId() const res await fetcher(${api_url}/api/v1/share/delete, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ share_id, owner_id }) }) if (!res.ok) throw new Error(Failed to delete share link) await deleteWebshare(id) return ok }即删除走POST /api/v1/share/delete携带share_id与owner_id服务端删除成功后扩展再调用 Dexie 的deleteWebshare移除本地索引。五、分享链接的生成流程源码级原理了解自托管配置后再看扩展端如何把一次聊天变成公开链接。分享入口位于聊天界面右上角更多选项菜单src/components/Layouts/MoreOptions.tsx点击后弹出分享弹窗ShareModalsrc/components/Common/ShareModal.tsx。弹窗表单分享弹窗包含两个必填字段标题title默认取当前聊天的历史标题通过getTitleById(historyId)读取姓名name分享页面中人类消息的显示名。表单下方会实时渲染该次聊天的全部消息预览确认无误后提交。消息重构提交前消息列表会经过reformatMessages重排src/components/Common/ShareModal.tsx每条消息被转换为{ id, name, isBot, message, reasoning_time_taken, search, images, modelName, modelImage, sources }结构。其中机器人消息的模型名会通过removeModelSuffix去掉厂商后缀如accounts/.../models/前缀人类消息则使用表单里填写的姓名。创建分享链接核心请求在onSubmit中发起src/components/Common/ShareModal.tsxconst onSubmit async (values: { title: string; name: string }) { const owner_id await getUserId() const chat reformatMessages(messages, values.name) const title values.title const url await getPageShareUrl() const res await fetcher(${cleanUrl(url)}/api/v1/share/create, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ owner_id, messages: chat, title }) }) if (!res.ok) throw new Error(t(share.notification.failGenerate)) const data await res.json() return { ...data, url: ${cleanUrl(url)}/share/${data.chat_id}, api_url: cleanUrl(url), share_id: data.chat_id } }关键调用链如下getUserId()获取或生成当前用户 ID —— 首次使用时生成形如user_xxxx-xxxx-xxxx-xxxx的随机 ID 并持久化src/db/dexie/helpers.ts向当前配置的分享服务器发送POST /api/v1/share/create请求体为{ owner_id, messages, title }服务端返回chat_id扩展据此拼接出公开访问地址{服务器地址}/share/{chat_id}链接生成后自动复制到剪贴板同时调用saveWebshare把{ title, url, api_url, share_id }存入本地数据库src/components/Common/ShareModal.tsx。本地记录存储分享记录存储在 Dexie 数据库的webshares表中相关方法定义在 src/db/dexie/chat.ts// Webshare Methods async getWebshare(id: string) { return await db.webshares.get(id) } async getAllWebshares(): PromiseWebshare[] { return await db.webshares.orderBy(createdAt).reverse().toArray() } async addWebshare(webshare: Webshare) { await db.webshares.add(webshare) } async deleteWebshare(id: string) { await db.webshares.delete(id) }saveWebsharesrc/db/dexie/helpers.ts会为记录生成唯一 ID 与时间戳按createdAt倒序排列这就是设置页表格中记录越新越靠前的来源。分享记录同样参与 Firefox 数据迁移流程见 src/db/dexie/migration.ts切换存储后端后历史分享记录不会丢失。六、自托管服务端需要提供的 API约定小结综合扩展源码一个可用的 Page Share 服务端至少要实现以下三个接口接口方法用途请求/响应要点/api/v1/pingGET健康检查返回纯文本pong供verifyPageShareURL校验/api/v1/share/createPOST创建分享请求体{ owner_id, messages, title }返回{ chat_id }/api/v1/share/deletePOST删除分享请求体{ share_id, owner_id }成功返回 2xx/share/{chat_id}GET公开访问页浏览器可渲染的公开聊天页面七、总结与部署建议Page Share 让 Page Assist 的本地对话可以像 ChatGPT Share 一样对外传播官方默认服务器开箱即用但涉及隐私敏感内容时应切换为自托管。实践中推荐快速验证先使用默认pageassist.xyz体验完整流程确认分享、查看、删除链路正常日常使用用 Railway 一键模板部署成本低、免运维强隐私场景用 Docker 在自有服务器部署配合反向代理与 HTTPS 加固并开启设置页的 Share Mode 开关让扩展每次保存前校验服务可用性。无论哪种方式配置完成后都可以在设置页的 Manage Share 区域统一管理服务器地址与历史分享记录整个闭环生成 → 存储 → 查看 → 删除均有对应的 设置页组件、分享弹窗、Dexie 数据层 与 校验工具 可查证。【免费下载链接】page-assistUse your locally running AI models to assist you in your web browsing项目地址: https://gitcode.com/GitHub_Trending/pa/page-assist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考