Q: 为什么 open-seo Docker 容器每次重启都会运行 `vite build`,并且需要 90 秒才能响应?

v0.1.0 自托管镜像会在其启动命令中无条件运行 `pnpm run build`，重新构建 Vite 客户端/SSR 包，并在提供服务前运行 `tsc --noEmit`。修复方法是使用包含 PR #120 的镜像：启动脚本会对内联进 Vite 的 `VITE_*` 变量连同镜像构建 ID 进行哈希，将构建输出缓存到持久化数据卷中，并在两者均未更改时跳过构建。该 PR 还移除了运行时的 `tsc --noEmit` 检查。请使用 `docker compose pull && docker compose up -d` 进行更新，并保持数据卷处于挂载状态。首次启动可能仍会执行构建；之后的重启应会跳过构建。更改与构建相关的 `VITE_*` 变量或更新镜像会触发重新构建。如果必须继续使用 v0.1.0，请自行构建或运行基于 PR #120 的镜像；旧镜像没有内置标志可以禁用启动时的构建。

Q: 为什么当 nextCheckAt 停留在过去的时间点且 lastSkipReason 为 null 时，计划的排名跟踪检查从不运行？

当定时排名检查的 cron 在更新 `nextCheckAt` 或创建运行记录之前失败时，就会发生这种情况。手动检查仍然可以成功，因为它走的是不同的代码路径。托管版本的问题已通过部署调度器提交 `f048dc3bd1c671e28aa4ceaaf22ca6663cdcb321` 和 `eec998a76233bb33e2dddbd921fc81da2eba1e0a` 修复；在发生与扩展相关的故障后，数据库容量也进行了扩容。对于自托管实例：1) 升级到包含这些提交的版本。2) 在 cron 日志中搜索 `[cron] Error processing config` 以及受影响的配置 ID，例如：`grep '\[cron\] Error processing config' app.log | grep -E 'aea7a4ae-b6f3-4334-8196-eb9406d20dbf|845f59d5-c4cd-440f-953a-2be68374ca38'`。3) 检查数据库的 CPU、连接数、延迟和资源耗尽情况，必要时进行扩容。4) 作为临时解决方案，手动使用 **Check rankings**；这会更新排名位置，但不会修复冻结的调度。5) 部署修复后，对于 `nextCheckAt` 仍然卡住的所有配置，请重新加入队列或联系支持团队。

Question 1

如何修复运行 pnpm dev 时出现的 SolidJS "No matching export ... for import 'use'" 错误？

Accepted Answer

当 `@tanstack/react-devtools` 0.10.12 拉入 `@tanstack/devtools-ui` 0.7.1 时会出现此问题，后者从 SolidJS 1.9.11 的服务端构建中导入 `use`，而该构建并未导出它。设置 `VITE_SHOW_DEVTOOLS=false` 并无帮助，因为 devtools 是在 `src/routes/__root.tsx` 中静态导入的。

临时解决方案：将 `@tanstack/react-devtools` 固定到最后一个兼容版本：

```json
"@tanstack/react-devtools": "0.10.8"
```

然后更新依赖：

```sh
pnpm install --no-frozen-lockfile
pnpm dev
```

这会解析为 `@tanstack/devtools-ui` 0.6.0，并允许开发服务器启动。更完善的永久修复方案是在 `src/routes/__root.tsx` 中通过仅限客户端的动态导入来加载 devtools，如提交 `db8bde17e245d01f9ca4ab06acaf37fe22aac361` 中所实现的。

Question 2

为什么网站审计会少统计字数，并对压缩后的 HTML 显示误报的 thin-content 警告？

Accepted Answer

这是 open-seo v0.1.16 之前版本中的一个 bug。无空格连接的块级标签（例如 `

one

two

`）会被解析为拼接文本（`onetwo`），导致字数统计降低，并触发误报的内容单薄警告。该问题还影响 `

`、`` 和 `
` 元素，并为等效的 HTML 生成不同的内容哈希值。修复方法：将 open-seo 升级到 v0.1.16 或更高版本（已在提交 756538cc5 中修复）。升级后，经过压缩和格式化的 HTML 会产生相同的字数统计和内容哈希值，而像 `OpenSEO` 这样的内联标记仍会被计为一个单词。

Question 3

如何阻止 SAM 聊天在我向上滚动阅读较早消息时自动滚回底部？

Accepted Answer

发生这种情况是因为聊天滚动容器在每次 `messages` 更新时都会被固定到底部。在 SAM 的流式响应期间,每个 token 都会触发更新,因此视图会立即被拉回底部。修复方法是升级到包含聊天自动滚动修复的版本。作为代码层面的临时解决方案,在 `SamConversation` 和 `OnboardingChatConversation` 中,仅当用户已接近底部时才执行自动滚动,例如:`const nearBottom = el.scrollHeight - el.scrollTop - el.clientHeight < 80; if (nearBottom) el.scrollTop = el.scrollHeight;`。不要在每次消息变更时强制设置 `scrollTop = scrollHeight`。

Question 4

为什么 open-seo Docker 容器每次重启都会运行 `vite build`,并且需要 90 秒才能响应?

Accepted Answer

v0.1.0 自托管镜像会在其启动命令中无条件运行 `pnpm run build`，重新构建 Vite 客户端/SSR 包，并在提供服务前运行 `tsc --noEmit`。修复方法是使用包含 PR #120 的镜像：启动脚本会对内联进 Vite 的 `VITE_*` 变量连同镜像构建 ID 进行哈希，将构建输出缓存到持久化数据卷中，并在两者均未更改时跳过构建。该 PR 还移除了运行时的 `tsc --noEmit` 检查。请使用 `docker compose pull && docker compose up -d` 进行更新，并保持数据卷处于挂载状态。首次启动可能仍会执行构建；之后的重启应会跳过构建。更改与构建相关的 `VITE_*` 变量或更新镜像会触发重新构建。如果必须继续使用 v0.1.0，请自行构建或运行基于 PR #120 的镜像；旧镜像没有内置标志可以禁用启动时的构建。

Question 5

为什么当 nextCheckAt 停留在过去的时间点且 lastSkipReason 为 null 时，计划的排名跟踪检查从不运行？

Accepted Answer

当定时排名检查的 cron 在更新 `nextCheckAt` 或创建运行记录之前失败时，就会发生这种情况。手动检查仍然可以成功，因为它走的是不同的代码路径。托管版本的问题已通过部署调度器提交 `f048dc3bd1c671e28aa4ceaaf22ca6663cdcb321` 和 `eec998a76233bb33e2dddbd921fc81da2eba1e0a` 修复；在发生与扩展相关的故障后，数据库容量也进行了扩容。对于自托管实例：1) 升级到包含这些提交的版本。2) 在 cron 日志中搜索 `[cron] Error processing config` 以及受影响的配置 ID，例如：`grep '$$cron$$ Error processing config' app.log | grep -E 'aea7a4ae-b6f3-4334-8196-eb9406d20dbf|845f59d5-c4cd-440f-953a-2be68374ca38'`。3) 检查数据库的 CPU、连接数、延迟和资源耗尽情况，必要时进行扩容。4) 作为临时解决方案，手动使用 **Check rankings**；这会更新排名位置，但不会修复冻结的调度。5) 部署修复后，对于 `nextCheckAt` 仍然卡住的所有配置，请重新加入队列或联系支持团队。

open-seo

项目简介

README 预览

常见问题 (5)

同类型项目

vscode

FreeDomain

stable-diffusion-webui

paperclip