GCWing · limityan · Aug 3, 2026 · Aug 3, 2026
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
@@ -147,11 +147,6 @@ jobs:
     steps:
       - uses: actions/checkout@v5
 
-      - name: Setup OpenSSL (Windows, prebuilt)
-        if: runner.os == 'Windows'
-        shell: pwsh
-        run: ./scripts/ci/setup-openssl-windows.ps1
-
       # Tauri code generation only requires its configured resource roots to
       # exist during check/test; distributable assets remain frontend-build's owner.
       - name: Create Tauri resource directories

diff --git a/.github/workflows/desktop-package.yml b/.github/workflows/desktop-package.yml
@@ -133,11 +133,6 @@ jobs:
         with:
           ref: ${{ needs.prepare.outputs.checkout_ref }}
 
-      - name: Setup OpenSSL (Windows, prebuilt)
-        if: runner.os == 'Windows'
-        shell: pwsh
-        run: ./scripts/ci/setup-openssl-windows.ps1
-
       - name: Install NSIS (Windows)
         if: runner.os == 'Windows'
         shell: pwsh

diff --git a/.github/workflows/nightly.yml b/.github/workflows/nightly.yml
@@ -100,11 +100,6 @@ jobs:
     steps:
       - uses: actions/checkout@v5
 
-      - name: Setup OpenSSL (Windows, prebuilt)
-        if: runner.os == 'Windows'
-        shell: pwsh
-        run: ./scripts/ci/setup-openssl-windows.ps1
-
       - name: Install Linux system dependencies (Tauri bundler)
         if: runner.os == 'Linux'
         shell: bash

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -23,17 +23,6 @@ but project scripts should run on Node.js 22.12+ unless a narrower local guide
 says otherwise. After switching from an older Node.js version, rerun
 `pnpm install`.
 
-#### Windows: OpenSSL Setup
-
-Most Windows contributors do not need to configure OpenSSL manually. Use
-`pnpm run desktop:dev` or the normal `desktop:build*` scripts; they bootstrap a
-pre-built OpenSSL package when needed.
-
-Only handle OpenSSL yourself when the bootstrap fails, you are preparing CI, or
-you intentionally use `pnpm run desktop:dev:raw`. In that case, run
-`scripts/ci/setup-openssl-windows.ps1`, or set `OPENSSL_DIR` to a pre-built x64
-OpenSSL directory and set `OPENSSL_STATIC=1`.
-
 #### Build Prerequisites Check
 
 When `cargo check --workspace`, `cargo check -p bitfun-desktop`, or pnpm build

diff --git a/CONTRIBUTING_CN.md b/CONTRIBUTING_CN.md
@@ -22,15 +22,6 @@ GitHub Actions 升级使用的是兼容 Node.js 24 的 action runtime，但项
 默认仍以 Node.js 22.12+ 为基线，除非局部指南另有说明。从旧 Node.js 版本切换
 后，请重新运行 `pnpm install`。
 
-#### Windows：OpenSSL 配置
-
-大多数 Windows 贡献者不需要手动配置 OpenSSL。使用 `pnpm run desktop:dev`
-或常规 `desktop:build*` 脚本即可；脚本会在需要时自动引导预编译的 OpenSSL 包。
-
-只有在自动引导失败、准备 CI 环境，或你明确使用 `pnpm run desktop:dev:raw`
-时才需要手动处理。此时运行 `scripts/ci/setup-openssl-windows.ps1`，或将
-`OPENSSL_DIR` 指向预编译的 x64 OpenSSL 目录，并设置 `OPENSSL_STATIC=1`。
-
 #### 构建前置检查
 
 当 `cargo check --workspace`、`cargo check -p bitfun-desktop` 或 pnpm 构建

diff --git a/Cargo.lock b/Cargo.lock
diff --git a/Cargo.toml b/Cargo.toml
@@ -121,7 +121,7 @@ encoding_rs = "0.8.35"
 url = "2"
 
 # HTTP client
-reqwest = { version = "0.13.4", default-features = false, features = ["native-tls", "rustls", "http2", "json", "stream", "multipart", "query", "form"] }
+reqwest = { version = "0.13.4", default-features = false, features = ["http2", "json", "stream", "multipart", "query", "form"] }
 semver = "1.0"
 
 # Debug Log HTTP Server

diff --git a/docs/architecture/platform-portability-design.md b/docs/architecture/platform-portability-design.md
@@ -100,7 +100,7 @@ Cargo package `bitfun-cli` 的 `aarch64-unknown-linux-ohos` 目标依赖解析
 | 进程与交互终端 | `portable-pty -> termios` 依赖 openpty、shell、信号、进程组和 `/dev` 语义 | 交互 shell、取消和子进程回收不成立 | OHOS 公开进程/PTY 能力与产品可接受的能力范围 |
 | 文件监听 | `notify` 在目标解析中选择 `inotify` | `target_os=linux` 导致错误后端选择；替代实现可能增加延迟和资源消耗 | 真机 watch 语义、性能预算和不可用时的产品状态 |
 | Git 与原生库 | `git2 -> libgit2-sys -> openssl-sys` 带入 CMake、zlib、OpenSSL 等原生构建 | 交叉编译、证书、凭据和行为一致性风险 | Git 能力的支持范围和可维护实现路径 |
-| 网络与 TLS | 当前闭包同时存在 native-tls、rustls、OpenSSL、aws-lc/ring 等路径 | 产物膨胀、证书来源错误、代理或流式响应异常 | OHOS 网络、根证书、代理、流式响应和取消能力 |
+| 网络与 TLS | Reqwest 已收敛为 Rustls + 平台证书验证；Git/libgit2 与其他协议仍有独立原生 TLS/加密路径，aws-lc/ring 选择也尚未针对 OHOS 验证 | 不能把通用客户端单栈误当成 OHOS 网络、证书或代理已适配 | OHOS 网络、根证书、代理、流式响应、取消能力，以及非 Reqwest 协议的 TLS 来源 |
 | 存储与路径 | `rusqlite/libsqlite3-sys`、`dirs` 及多处路径探测依赖桌面/类 Unix 假设 | 会话损坏、凭据泄露、升级后路径漂移 | 配置、数据、缓存、日志、凭据与工作区边界 |
 | Tokio 与平台条件 | `tokio(full)` 打开 process、signal、net、fs；源码存在大量 `cfg(unix)`、`cfg(not(windows))` | 未使用能力扩大闭包；OHOS 错走 Linux 分支 | 实际可达能力、系统调用兼容性和取消/事件语义 |
 | 用户发行与支持 | 普通用户 native CLI 安装、系统终端入口和升级渠道尚未证明 | 开发探针被包装成产品；支持范围无法维护 | 支持的设备、系统、终端、渠道与生命周期 |

diff --git a/docs/architecture/rust-build-dependency-boundaries.md b/docs/architecture/rust-build-dependency-boundaries.md
@@ -62,6 +62,14 @@ Cargo 会统一同一 package 在依赖图中的 feature；workspace dependency
 - target-specific dependency 放在最接近平台实现的 owner，不因单一平台需求污染跨平台 crate；
 - 修改共享 dependency feature 视为构建影响变更，必须检查真实产品组合的 feature graph。
 
+### 3.4 Reqwest TLS 后端由客户端 owner 选择
+
+- workspace 级 `reqwest` 只统一版本以及跨产品共享的 HTTP、序列化和流能力，不启用 TLS 后端；
+- 真正创建 HTTPS client 的 app、service 或 adapter 必须在自身依赖声明中显式选择 `reqwest/rustls`，只使用 `reqwest::Url` 的 contract/assembly 路径不加载 TLS；
+- capability crate 的每个 Reqwest owner feature 必须独立带齐 `reqwest/rustls`，不能依赖 `product-full` 或其他 feature 的 Cargo feature-union 偶然补齐；
+- 边界检查以 Cargo metadata 的解码结果看护全部直接 consumer，并检查 resolved Reqwest feature union，防止传递依赖重新激活 Native TLS；
+- 不并列启用 native-tls 兼容栈。只有真实产品场景无法由 Rustls 平台证书验证承载时，才以明确行为证据评审替换方案，而不是重新叠加第二后端。
+
 ## 4. 依赖 owner 与准入检查
 
 第三方库应位于调用外部系统或实现具体能力的最低合理 owner：

diff --git a/docs/performance/01-compile-performance.md b/docs/performance/01-compile-performance.md
@@ -20,7 +20,7 @@
 | F7 | CI:`rust-build-check` 串行等待 `frontend-build`(含大量 lint/audit/test)完成才开始 | CI | 中 | `.github/workflows/ci.yml:72` |
 | F8 | 每次 `desktop:dev` 无条件重建 mobile-web(先删 target 内产物 + pnpm install + vite build) | 脚本 | 中 | `scripts/dev.cjs:704-714`、`scripts/mobile-web-build.cjs:75-133` |
 | F9 | 依赖树重复严重:1177 个包中 112 个名字存在多版本(image、thiserror、rand×3、getrandom×4、windows-sys×6、phf×6 等) | Rust | 中 | Cargo.lock 解析;`src/apps/desktop/Cargo.toml:85`(image 0.24 vs workspace 0.25) |
-| F10 | reqwest 同时启用 native-tls + rustls,双 TLS 栈都参与编译 | Rust | 中 | `Cargo.toml:121` |
+| F10 | reqwest TLS 单栈治理（已完成） | Rust | 已兑现 | workspace transport-only + 客户端 owner 显式 Rustls；见 F10 治理结果 |
 | F11 | Vite dev watcher 强制 usePolling + 100ms 轮询,Windows 上 CPU 高、拖慢 HMR | 前端 | 中 | `src/web-ui/vite.config.ts:68-74` |
 | F12 | prompts/公告 md 内嵌进 bitfun-core 的 build.rs 生成代码,改一个提示词 = 重编 202k 行 core + 下游 | Rust | 中 | `src/crates/assembly/core/build.rs:110-183,343-401` |
 | F13 | beforeBuildCommand 内 web 构建与 mobile-web 构建纯串行;dev.cjs 准备步骤也全串行 | 脚本 | 中 | `src/apps/desktop/tauri.conf.json`(build 块)、`scripts/dev.cjs:668-737` |
@@ -149,15 +149,15 @@ Cargo.lock 共 1177 个包,其中 112 个名字存在 2 个以上版本(解析
 2. 运行 `cargo tree -d -e normal --workspace`(建议加 `--target x86_64-pc-windows-msvc` 过滤无关平台)输出清单,针对 top 传递源头(如 pull 出 rand 0.7 的 crate)评估升级;`russh 0.45`、`screenshots 0.8`、`syntect-tui` 等旧版是主要嫌疑。
 3. 将该清单纳入 nightly CI 做趋势看护(非阻断)。
 
-### F10(中)reqwest 同时启用 native-tls 与 rustls
+### F10(已治理)reqwest TLS 单栈
 
-**问题描述**
-`Cargo.toml:121`:`reqwest = { ..., features = ["native-tls", "rustls", ...] }`。两套 TLS 栈(schannel/native-tls + rustls/ring)全部参与编译;workspace 另有独立 `rustls`(267 行)与 `tokio-tungstenite rustls-tls-native-roots`(245 行),说明 rustls 反正逃不掉,native-tls 则额外拖上 openssl-sys 相关生态(Windows 上还催生了 `ensure-openssl-windows.mjs` 整套预编译 OpenSSL bootstrap)。
-
-**预期收益**:中(冷构建时间;若能移除 native-tls,Windows 构建可望摆脱 OpenSSL bootstrap 依赖链)。
+**治理结果（2026-08-03）**
+- workspace 级 `reqwest` 只保留 HTTP/序列化能力，URL-only 消费者不再被动加载 TLS；CLI、Desktop、AI Adapter、MiniApp Market 与 Services 的各 Reqwest owner feature 显式选择 Rustls。
+- Reqwest 0.13 的 `rustls` feature 使用平台证书验证器，保留系统信任根行为；三处显式 Client Builder 统一使用 `tls_backend_rustls()`，不再混用默认后端或弃用 API。
+- `Cargo.lock` 已移除 `native-tls`、`hyper-tls`、`tokio-native-tls`、`openssl` 与 `openssl-macros`；`openssl-sys` 只剩非 Windows 的 Git/libgit2 目标路径。Windows 产品图、本地开发、常规构建和三个既有 workflow 不再下载或配置预编译 OpenSSL。
+- 边界检查约束 TLS 必须由真实客户端 owner 选择，避免未来把后端重新提升为 workspace 全局 feature；没有新增 CI job 或测试步骤。
 
-**优化方案**
-- 审计运行时实际选用的 TLS(代码中 `Client::builder().use_native_tls/use_rustls` 调用点),统一到 rustls(`rustls-tls-native-roots` 以保留系统根证书行为),移除 `native-tls` feature;git2 侧确认 `https` feature 的 TLS 来源后同步评估。风险:企业代理/自签证书环境行为差异,需回归远端连接类功能。
+**收益与风险**:Windows CI 每个受影响 job 省去约 6.6 秒 OpenSSL bootstrap（以 PR #1991 的 Windows job 步骤时间戳为基线），并减少一套 TLS 依赖闭包。显式代理配置仍由 Reqwest 处理；未受系统信任的自签证书仍会按安全默认值拒绝。仓库没有 Reqwest client identity 或自定义 native connector 用法，因此未保留第二后端兼容层。
 
 ### F11(中)Vite dev 强制 100ms 轮询 watch
 
@@ -247,7 +247,7 @@ Cargo.lock 共 1177 个包,其中 112 个名字存在 2 个以上版本(解析
 | T8 | 提交 Cargo.lock(F6):从 `.gitignore:26` 移除并提交根与 installer 两份 lockfile;CI 删除 `cargo generate-lockfile` 步骤;建立定期依赖更新流程后逐步解除 `Cargo.toml:98-107` 的 `=` 钉版。验收:rust-cache 命中率上升,CI 不再因上游发版突然变慢/失败。 | `.gitignore`、`.github/workflows/*.yml`、`Cargo.toml` | 中(流程变更,需团队确认依赖更新策略) |
 | T9 | Vite watch 去轮询(F11):删除 `src/web-ui/vite.config.ts:68-74` 的 `usePolling/interval`,保留 ignored 列表;以 `VITE_USE_POLLING=1` 环境变量作为网络盘用户逃生口。验收:dev server 空闲 CPU 占用明显下降,HMR 正常。 | `src/web-ui/vite.config.ts` | 低(个别特殊文件系统需逃生口) |
 | T10 | build.rs 确定性输出(F18):`assembly/core/build.rs` 与 `src/apps/cli/build.rs` 生成代码前对 key 排序(HashMap→BTreeMap)。验收:连续两次 clean build 生成的 OUT_DIR 文件字节一致。 | `src/crates/assembly/core/build.rs`、`src/apps/cli/build.rs` | 低 |
-| T11 | reqwest TLS 单栈(F10):审计 `use_native_tls/use_rustls` 调用点后,从 `Cargo.toml:121` 移除 `native-tls` feature,统一 rustls-tls-native-roots;回归远端连接/订阅鉴权/代理场景;评估 Windows OpenSSL bootstrap 链能否随之精简。验收:Cargo.lock 无 native-tls/openssl-sys(git2 除外),网络功能回归通过。 | `Cargo.toml:121`、相关调用点 | 高(TLS 行为变化,企业代理/自签证书场景需重点回归;可放最后) |
+| T11（已完成） | reqwest TLS 单栈(F10):workspace 保持 transport-only，由真实客户端 owner 显式选择 Rustls；删除 native-tls 与无消费者的 Windows OpenSSL bootstrap，保留平台证书验证。验收:Cargo.lock 无 native-tls；Windows 产品图无 openssl-sys，非 Windows 的 Git/libgit2 路径不变；相关最小 feature 与产品入口编译通过。 | 根与客户端 owner `Cargo.toml`、相关调用点、既有 workflow | 已完成；平台信任根行为保留，无第二后端兼容层 |
 | T12 | beforeBuildCommand 并行(F13):新增 `scripts/frontend-build-all.mjs` 并行跑 build:web 与 prepare:mobile-web,tauri.conf.json / tauri.dev.conf.json 的 beforeBuildCommand 指向它;dev.cjs 准备步骤改 Promise.all。验收:desktop:build 前端阶段时长≈max(两者) 而非 sum。 | `src/apps/desktop/tauri.conf.json`、`tauri.dev.conf.json`、`scripts/dev.cjs`、新脚本 | 低 |
 | T13 | bitfun-core 拆分启动(F3,长期):先跑 `cargo build --timings` 与 `cargo tree -d` 存档基线;选 1-2 个低耦合子域(如 announcement、debug-log server)试点拆出独立 crate 并保留 re-export;结合 F12 的"dev 运行时读取提示词"改造。验收:改动试点子域后 `cargo build -p bitfun-desktop` 的重编 crate 数与耗时下降。 | `src/crates/assembly/core/**`、根 `Cargo.toml` members | 中-高(架构改动,分多个 PR 渐进) |
 | T14 | 可选工具链增强(F5):提交 `.cargo/config.toml` 模板(注释形式提供 rust-lld 与 sccache 配置,默认不启用),团队自选开启;CI 冷构建可评估 sccache-action。验收:提供文档,默认行为不变。 | 新增 `.cargo/config.toml`、文档 | 低(默认关闭) |
@@ -263,4 +263,4 @@ T2 + T4 + T5 + T6 + T9 + T10 + T12:全部低风险,合计可显著改善日常 d
 - `BitFun-Installer/src-tauri/Cargo.toml:61-65` 的 release profile 同样是 `lto=true + codegen-units=1`(opt-level="z"),T3 的 thin LTO 评估可一并覆盖。
 - Cargo.lock:1177 个包,112 个存在多版本(windows-sys ×6、phf ×6、getrandom ×4、nix ×4、rand ×3、quick-xml ×4 等)。
 - 前端:web-ui 1676 个 TS/TSX、366,580 行;dist 共 872 个 asset,JS 总量 14.3MB,入口 chunk 5.4MB(含 Monaco 内核);public/monaco-editor 14MB/103 文件。
-- 现有良好实践(保持):release-fast profile(Cargo.toml:288-293)、cargo-target-gc 缓存清理、Windows 预编译 OpenSSL、sherpa-onnx prebuilt、CI CARGO_INCREMENTAL=0 + debug=0(ci.yml:74-77)、swatinem/rust-cache、pnpm store 缓存、workspace.dependencies 统一版本声明。
+- 现有良好实践(保持):release-fast profile(Cargo.toml:288-293)、cargo-target-gc 缓存清理、Reqwest Rustls 单栈与平台证书验证、sherpa-onnx prebuilt、CI CARGO_INCREMENTAL=0 + debug=0(ci.yml:74-77)、swatinem/rust-cache、pnpm store 缓存、workspace.dependencies 统一版本声明。