# doc_proofreading_service

**Repository Path**: rumosky/doc_proofreading_service

## Basic Information

- **Project Name**: doc_proofreading_service
- **Description**: 一个文档校对工具的服务端
- **Primary Language**: Unknown
- **License**: AGPL-3.0
- **Default Branch**: app
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2025-09-26
- **Last Updated**: 2026-10-12

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# doc-proofreading-service

这是一个文档校对服务项目。

自用，不对外，不提供服务

<br />

```bash
.\release.ps1 -Notes "1. 新增多轮对话`n2. 修复思考过程显示顺序`n3. 移除无效的温度设置`n4. 新增自动更新"

# 两个渠道一起发（最常用）
.\release.ps1 -Notes "1.修复xxx 2.优化xxx"

# Win7 单独写更新说明
.\release.ps1 -Notes "主线更新说明" -Win7Notes "Win7 渠道说明"

# 只发其中一个渠道
.\release.ps1 -Notes "..." -SkipWin7
.\release.ps1 -Notes "..." -SkipMain
```

## 安装包分发：为什么用魔搭 ModelScope（Gitee 100MB 上限）

Win7 安装包内嵌了 WebView2 109 固定运行时，**约 150MB**，超过 Gitee Release 附件的**单文件 100MB 上限**；
用户又无法访问 GitHub。因此安装包改托管到**魔搭 ModelScope**（阿里出品，国内直连、免费、**无容量上限**，
大文件走 git LFS），公开仓库的文件直链任何人可匿名直接下载，正好供 Tauri updater 使用。

**分工**：

- 更新清单 `latest.json` / `latest-win7.json`（几 KB）仍然推 **Gitee** 的 `app` 分支，用户检查更新时从这里读；
- 安装包（`.exe`，约 7MB / 150MB）推到**魔搭公开仓库**，清单里的下载地址写成魔搭匿名直链。

首次使用：

1. 注册并登录 [modelscope.cn](https://modelscope.cn)，右上角「创建模型」建一个**公开**仓库（名字随意，如 `doc-proofreader`，类型选通用模型即可，本质是个带 LFS 的文件仓库）。
2. 在[访问令牌页](https://modelscope.cn/my/access/token)创建一个 Token。
3. 发布时传入魔搭用户名/仓库名，Token 建议用环境变量（避免写进命令历史）：

```powershell
$env:MODELSCOPE_TOKEN = '你的魔搭访问令牌'
.\release.ps1 -Notes "..." -ModelScopeUser "rumosky" -ModelScopeRepo "doc-proofreader"
```

```powershell
.\release.ps1 -Notes "..." -ModelScopeUser "rumosky" -ModelScopeRepo "doc-proofreader" -ModelScopeToken ""
```

脚本会在两个渠道构建完成后，自动把安装包用 git LFS 推到魔搭仓库根目录（固定文件名覆盖、直链不变），
并把清单里的 url 写成 `https://www.modelscope.cn/models/<用户>/<仓库>/resolve/master/<文件名>`。
你只需像以前一样把 `latest.json` / `latest-win7.json` 提交推送到 Gitee 的 `app` 分支即可，**不用再传 Gitee Release**。

> 不传 `-ModelScopeUser/-ModelScopeRepo` 时脚本沿用旧的 Gitee Release 附件方式（但 Win7 包会超 100MB，传不上）。
> 本机需装有 Git for Windows（自带 git-lfs），脚本依赖它完成推送。

## Win7 兼容版的 WebView2 固定运行时

Win7 / Win8 / Win8.1 只能用 **WebView2 Runtime 109**（109 是支持这些系统的最后一个大版本；110 及以上安装时会报 `无法定位程序输入点 PackageIdFromFullName 于动态链接库 KERNEL32.dll`）。

Win7 渠道（[tauri.win7.conf.json](src-tauri/tauri.win7.conf.json)）用 `fixedRuntime` 模式把运行时**内嵌**进安装包，因此构建前需要先把运行时放到 `src-tauri/webview2-fixed/`。该目录已在 `.gitignore` 中、**不入库**，换电脑 / 重装系统后需重新拉取。运行时从 NuGet 包 `WebView2.Runtime.X64` 的 `109.0.1518.78` 版本获取。

在**项目根目录**用 PowerShell 执行（自动下载 + 解压 + 就位）：

```powershell
$ErrorActionPreference = 'Stop'
$ver = '109.0.1518.78'
$tmp = Join-Path $env:TEMP "wv2-$ver"
$pkg = "$tmp\wv2.zip"                       # .nupkg 本质就是 zip，改后缀用 Expand-Archive 解压
New-Item -ItemType Directory -Force -Path $tmp | Out-Null

# 1. 下载 NuGet 包
curl.exe -sL "https://api.nuget.org/v3-flatcontainer/webview2.runtime.x64/$ver/webview2.runtime.x64.$ver.nupkg" -o $pkg

# 2. 解压
Expand-Archive -Path $pkg -DestinationPath $tmp -Force

# 3. 取出运行时目录到 src-tauri/webview2-fixed（保证 msedgewebview2.exe 在该目录根下）
$dst = Join-Path $PWD 'src-tauri\webview2-fixed'
Remove-Item $dst -Recurse -Force -ErrorAction SilentlyContinue
Copy-Item (Join-Path $tmp 'contentFiles\any\any\WebView2') $dst -Recurse -Force

# 4. 校验（应输出 True）
Test-Path (Join-Path $dst 'msedgewebview2.exe')

# 清理临时文件
Remove-Item $tmp -Recurse -Force
```

手动下载地址（备用）：

- NuGet 包页：<https://www.nuget.org/packages/WebView2.Runtime.X64/109.0.1518.78>
- 直链：<https://api.nuget.org/v3-flatcontainer/webview2.runtime.x64/109.0.1518.78/webview2.runtime.x64.109.0.1518.78.nupkg>
  - 下载后把 `.nupkg` 改名为 `.zip` 解压，将里面 `contentFiles/any/any/WebView2/` 目录的**全部内容**复制到 `src-tauri/webview2-fixed/`（确保 `msedgewebview2.exe` 位于该目录根下）。

放好后正常执行 `.\release.ps1` 即可同时打主线 + Win7 两个渠道；只想单独出一个 Win7 包可执行 `pnpm tauri:win7`。

## Win7 兼容版的 Rust 工具链要求

除了内嵌 WebView2 109，Win7 渠道还必须用**专门的 Rust 目标**编译，否则安装能成功、但一打开就报
`无法定位程序输入点 GetSystemTimePreciseAsFileTime 于动态链接库 kernel32.dll 上`（还可能伴随
`WaitOnAddress`、`ProcessPrng` / `bcryptprimitives.dll` 等）。

原因：**Rust 1.78 起，`x86_64-pc-windows-msvc` 目标的预编译标准库最低系统基线提升到了 Windows 10**，
标准库会静态链接一批 Win7 没有的系统 API。解决办法是改用官方 Tier 3 目标
`x86_64-win7-windows-msvc`，配合 `build-std` 从源码重新编译标准库，生成的程序只依赖 Win7 可用的 API。
`release.ps1` 在构建 Win7 渠道时会自动加上 `--target x86_64-win7-windows-msvc` 并开启 `build-std`，
但需要本机具备以下条件（换电脑 / 重装系统后要重新准备）：

```powershell
# 1. 安装 rust-src 组件（build-std 编译标准库需要源码）
rustup component add rust-src

# 2. 安装 MSVC 构建工具（Visual Studio Build Tools，含 C++ 桌面开发负载）
#    与主线构建同一套即可，无需额外安装
```

> `build-std`（`-Z` 不稳定开关）原本只在 nightly 可用，脚本通过设置 `RUSTC_BOOTSTRAP=1`
> 让当前 stable 工具链也能使用，因此**无需额外安装 nightly**。脚本仅在编译 Win7 渠道时临时设置
> `RUSTC_BOOTSTRAP` 和 `CARGO_UNSTABLE_BUILD_STD`，构建结束即还原，不影响主线构建。

> **正常发布无需关心下面这些细节**：`release.ps1` 构建 Win7 渠道时会自动设置 `RUSTC_BOOTSTRAP` /
> `CARGO_UNSTABLE_BUILD_STD`，并自动处理 tauri-cli 的 target 校验（见下一小节），构建结束即还原。
> 直接跑 `.\release.ps1 -Notes "..."` 即可。

手动单独编译 Win7 版本（不走 release.ps1 时），除了 build-std 还必须**临时把 rustup 从 PATH 隐藏**，
否则 tauri-cli 会报 `Target x86_64-win7-windows-msvc does not exist`（原因见下一小节）：

```powershell
$env:RUSTC_BOOTSTRAP = "1"
$env:CARGO_UNSTABLE_BUILD_STD = "std,panic_abort"   # release profile 为 panic=abort

# 绕过 tauri-cli 的 Tier 3 target 校验：用工具链真实 bin 前置，并从 PATH 移除 ~/.cargo\bin（rustup 所在）
$sysroot = rustc --print sysroot
$cargoBin = Join-Path $env:USERPROFILE ".cargo\bin"
$env:PATH = "$(Join-Path $sysroot 'bin');" + (($env:PATH -split ';') | Where-Object { $_ -and ($_.TrimEnd('\') -ne $cargoBin.TrimEnd('\')) }) -join ';'

pnpm tauri build --features win7-channel `
  --config src-tauri/tauri.win7.conf.json `
  --target x86_64-win7-windows-msvc
# 产物在 src-tauri\target\x86_64-win7-windows-msvc\release\bundle\nsis\
```

> 注意：`pnpm tauri:win7`（package.json 里的快捷脚本）**不带** `--target`、`build-std`，也不隐藏 rustup，
> 编出来的仍是 Win10 基线的包、Win7 打不开。发布 Win7 包请用 `.\release.ps1`，或按上面的手动命令执行。

### 为什么 Win7 构建要把 rustup 从 PATH 隐藏

tauri-cli（`tauri build`）在调用 cargo 前，会执行 `rustup target list` 校验 `--target` 是否存在：
**只有当 rustup 命令能成功运行时才校验**。而 `x86_64-win7-windows-msvc` 是 Rust 的 Tier 3 目标，
rustup 既没有它的预编译标准库、也无法 `rustup target add`，于是 tauri-cli 直接报
`Target x86_64-win7-windows-msvc does not exist` 并中止——哪怕我们其实是用 `build-std` 从源码编译标准库、
根本不需要 rustup 安装该目标。

利用的机制：rustup 的代理程序（cargo/rustc/rustup）只在 `~/.cargo\bin`，而当前工具链的**真实**
`cargo.exe` / `rustc.exe` 在 `~/.rustup\toolchains\<toolchain>\bin`（该目录里**没有** rustup.exe）。
所以 `release.ps1` 在 Win7 构建时临时把 PATH 里的 `~/.cargo\bin` 移除、前置工具链真实 bin：
tauri-cli 找不到 rustup.exe → `rustup target list` 启动失败 → 跳过 target 校验；而 cargo/rustc 仍由
工具链真身提供，`build-std` 借助 sysroot 内已安装的 `rust-src` 正常编译。构建结束后 PATH 原样还原，
不影响主线构建。

### 为什么仓库里有 `src-tauri/vendor/ctor` 和 `vendor/dtor`

Win7 目标 `x86_64-win7-windows-msvc` 的 `target_vendor` 是 `"win7"`（普通 Windows 目标是 `"pc"`）——
正是这个特殊 vendor 让 Rust 标准库走 Win7 兼容代码路径，**不能改**。但 `ctor` / `dtor` 这两个依赖
（Tauri 间接引入）旧版本用 `target_vendor = "pc"` 来判断"是不是 Windows"，遇到 win7 目标会直接
报 `#[ctor]/#[dtor] is not supported on the current target`。

因此在 [Cargo.toml](src-tauri/Cargo.toml) 里用 `[patch.crates-io]` 把这两个 crate 指向仓库内的
vendored 副本（[vendor/ctor](src-tauri/vendor/ctor)、[vendor/dtor](src-tauri/vendor/dtor)），
仅把 Windows 判断从 `target_vendor = "pc"` 改为 `target_os = "windows"`（对普通 Win10/11 目标行为完全等价）。
这两个目录**已入库**，换电脑 / 重装系统后 `git clone` 即可自动生效，无需额外操作；
也不要把它们加进 `.gitignore`。