Pake 的 Rust/Tauri 工程铁律CLI 错误处理、配置类型安全与 IPC 信任边界【免费下载链接】Pake Turn any webpage into a desktop app with one command.项目地址: https://gitcode.com/GitHub_Trending/pa/Pake本文基于 Pake 仓库中的规则文件.claude/rules/rust.md展开系统讲解该项目的三组核心工程约定面向用户的错误处理规范、Tauri 配置的类型安全要求以及“打包进应用的远程页面不可信”这一 Tauri 信任边界原则。读完本文你可以掌握 Pake 中PakeError、--json机器模式、PakeTauriConfig类型体系的完整落地方式并能理解为什么 Pake 强调“永远不要靠 grep 错误消息来分类构建失败”。规则文档的定位Pake 特有的 Rust Tauri 约束Pake 是一个“一条命令把任意网页打包成桌面应用”的工具Turn any webpage into a desktop app with one command。它的技术栈分为两层CLI 构建层TypeScript位于bin/目录负责解析参数、合并配置、驱动 Tauri/cargo/linuxdeploy 等子进程完成打包运行时壳层Rust Tauri位于src-tauri/目录被打包进每一个生成的桌面应用负责窗口管理、导航保护、IPC 命令等运行时行为。.claude/rules/rust.md开篇即声明了自身边界标准 Rust 卫生?优先于unwrap()、cargo clippy零告警、提交前cargo fmt默认成立不再重复dist/cli.js的重建规则、CN 镜像策略、平台敏感规则Linux/Wayland WebKit 合成、AppImage 警告噪音、--incognito、内嵌 WebView OAuth 等都放在 AGENTS.mdCurrent Risk Areas / Network Mirror Behavior 章节本文不重复。也就是说这份规则文件聚焦的是三件跨两层技术栈都必须守住的 Pake 特有约定错误处理、配置类型、Tauri 信任边界。下面逐一拆解并用仓库源码印证每条规则的落地实现。错误处理四条铁律与它们的源码实现规则原文对错误处理提出了四条要求每一条都能在bin/目录下找到对应的实现证据。铁律 1用户可达路径上禁止panic!/.unwrap()/.expect()在用户可达的路径上CLI 选项解析、配置加载、事件处理器、IPC 命令不得使用panic!/.unwrap()/.expect()应使用?向上抛出并给出清晰信息。这条规则横跨两层代码。Rust 侧对应src-tauri/中被打包进用户应用的代码——一旦用户在某个打包出来的应用里触发 IPC 命令崩溃整个桌面应用直接挂掉这比 CLI 报错严重得多。TypeScript 侧对应 CLI 的任何用户交互路径。铁律 2静默吞错必须至少升级为logger.warnTS 中的catch {}或 Rust 中的let _ ...这类静默吞错至少要通过logger.warn把真实错误暴露出来。注意logger.warn同时会流入--json结果的warnings数组状态行应使用logger.info。这里的细节很值得展开。Pake 的日志封装在 bin/options/logger.ts 中基于loglevelchalk实现info/debug/error/warn/success五个方法。而在机器模式下--jsonbin/utils/output.ts#L56-L67 中的enableMachineMode()会接管 loglevel 的methodFactory所有日志被重定向到 stderr其中warn级别的条目会被额外捕获进capturedWarnings最终进入 JSON 结果的warnings数组。这意味着logger.warn和logger.info的语义分界不是随意偏好而是契约warn会被机器读到进入warnings: string[]info只作为人类可读的状态行。规则文档特意点出这一点bin/builders/BaseBuilder.ts#L240-L244 中的注释也是同一逻辑// Show static message to keep the status visible. Info, not warn: warn // entries feed the --json warnings array and this is a status line. logger.info(✸ Building app...);--json模式下最终输出的结构定义在 bin/utils/output.ts#L35-L47export interface PakeJsonResult { ok: boolean; name: string | null; platform: NodeJS.Platform; arch: string | null; outputs: BuildArtifact[]; warnings: string[]; // ← logger.warn 的捕获结果 error: { code: PakeErrorCode; message: string; hint: string | null; } | null; }铁律 3可预期的失败抛PakeError {code, hint}退出码稳定可映射可预期的 CLI 失败应抛出带{code, hint}的PakeError定义于bin/utils/error.tscode映射到稳定的退出码和--json错误对象普通的Error则由bin/cli.ts按构建阶段build phase分类。实现见 bin/utils/error.ts#L12-L35export class PakeError extends Error { readonly isUserError true; readonly code?: PakeErrorCode; // INVALID_INPUT | ENV_MISSING | BUILD_FAILED | NETWORK | UNEXPECTED readonly hint?: string; // 给用户的下一步建议 // ... }退出码契约写死在 bin/utils/output.ts#L19-L27code退出码含义INVALID_INPUT2输入不合法BUILD_FAILED/NETWORK3构建或网络失败ENV_MISSING4缺少运行环境如未装 RustUNEXPECTED1未预期错误bin/cli.ts顶层的classifyError逻辑遵循“带显式code的PakeError优先于阶段默认值”的原则如果抛出的不是PakeError则按当前所处阶段input→prepare→build见bin/cli.ts中phase变量的推进套用阶段默认code。这样 CI/Agent 可以仅凭退出码判断失败类别不需要解析终端文本。一个真实用例BaseBuilder.prepare()检测不到 Rust 且处于非交互模式时抛出new PakeError(Rust required to package your webapp., { code: ENV_MISSING, hint: Install Rust via https://rustup.rs, then rerun the same command. })见 bin/builders/BaseBuilder.ts#L135-L157。铁律 4--json机器模式下 stdout 只属于唯一的 JSON 结果机器模式下 stdout 被唯一的 JSON 结果独占。bin/中任何地方都不得console.log/process.stdout.write子进程 stdout 由shellExec重定向到 stderr。这条规则的实现分两处日志层enableMachineMode()将所有 loglevel 输出改写到console.errorstderr并关闭 chalk 颜色保证 stdout 干净可JSON.parse子进程层bin/utils/shell.ts#L11-L19 中execa的 stdio 配置为stdout: isMachineMode() ? process.stderr : inherit——交互模式实时透传linuxdeploy、cargo、npm的输出即时可见机器模式重定向到 stderr。shellExec陷阱为什么不能靠 greperror.message分类构建失败规则文档中最有分量的一段是shellExec用stdio: inherit运行子进程因此它们的输出linuxdeploy、cargo、npm永远不会进入error.message只有失败的命令行会进入。不要通过 greperror.message来分类构建失败——那匹配到的是命令而不是诊断信息。失败引导应基于调用方持有的结构化事实例如target appimage。责任方bin/utils/shell.tsbin/builders/BaseBuilder.ts。这个约束的根源在 bin/utils/shell.ts#L25-L40stdio: inherit意味着子进程诊断直接流到终端execa抛出的error.message里只包含命令字符串本身。所以“从错误文本判断失败原因”这条路在架构上就是死的。正确的做法示范就在 bin/builders/BaseBuilder.ts 的 Linux AppImage 失败处理中调用方天然持有结构化事实isLinuxAppImage process.platform linux target appimageL255-L256于是它第一次构建失败后基于该事实自动用NO_STRIP1重试一次glibc 2.38 的 strip 兼容问题是 AppImage 最常见的失败原因重试仍失败时把APPIMAGE_FAILURE_GUIDANCEL34-L53追加到错误消息中——这份引导不声称知道具体原因注释明确写道 “we cannot name the exact cause”而是列出全部已知原因与修复命令gdk-pixbuf loaders 缺失给出 Arch/Debian/Fedora 三种发行版的安装命令、Docker 容器缺/dev/fuse时的启动参数、以及退路方案pake url --targets deb详细指南指向 docs/faq.md。这个设计是“铁律 3 铁律 4”的合力产物hint/引导文本承担给人类的下一步建议退出码与code承担给机器的分类而具体诊断则留在终端由用户自行阅读——三层各司其职。配置类型安全禁止tauriConf: any规则原文不允许tauriConf: any或其他无类型配置袋。使用PakeTauriConfig。 窗口选项分布在bin/helpers/cli-program.ts、bin/types.ts、bin/defaults.ts、bin/helpers/merge.ts四处。新增一个选项意味着要同时改这四个文件再加上schema/pake.schema.json和docs/cli-usage*.md。漏掉任何一个都是回归其中 schema 那半边由tests/unit/config-file.test.ts兜底。这条规则针对的是 Pake 的工作流本质CLI 选项最终会被合并写进一个临时的src-tauri/.pake/tauri.conf.json供 Tauri 构建使用见 bin/builders/BaseBuilder.ts#L475-L483。如果配置是无类型的any袋任何一个拼写错误都只会表现为“选项悄悄不生效”而不是编译错误。类型体系定义在 bin/types.ts核心有三个接口PakeTauriConfigL213-L241对 Tauri 配置结构的类型化描述包含productName、identifier、version、mainBinaryName、pake: PakeConfig、bundle含各平台细分字段等PakeConfig/WindowConfigL171-L211Pake 自有配置块的结构WindowConfig的字段hide_title_bar、always_on_top、internal_url_regex、zoom、min_width等与 CLI 选项一一对应PakeCliOptionsL4-L159全部 CLI 选项的完整类型定义每个字段带默认值注释如width默认 1200、zoom默认 100、bundle默认 true 等可作为参数速查表。运行时装配逻辑在 bin/helpers/tauriConfig.ts它从 npm 包目录读取src-tauri/pake.json和tauri.conf.json再按process.platform选择tauri.windows.conf.json/tauri.macos.conf.json/tauri.linux.conf.json之一仅取其中的bundle与app.trayIcon平台差异字段合并出最终基线配置。“新增选项五处必改”清单cli-program.ts解析 types.ts类型 defaults.ts默认值 merge.ts合并 schema/pake.schema.json校验 docs/cli-usage*.md与docs/cli-usage_CN.md文档本质上是一张变更影响面清单tests/unit/config-file.test.ts 负责在测试中拦截“schema 忘了加字段”这一类最常见的遗漏。Tauri 信任边界打包进去的远程页面是不可信输入规则原文三条要求打包进应用的远程页面是不可信的。每个#[tauri::command]的输入都必须做语义边界校验远程页面的 capability 保持“恰好够用”长时间运行的 IPC 保持异步让页面代码无法阻塞应用主循环。为什么这是 Pake 必须单独写进规则的一条因为 Pake 打包的恰恰是任意的第三方网页——任何用户都可以对任何 URL 执行pake url。生成的应用里WebView 加载的页面代码与 Rust 侧的 Tauri 命令之间只隔一层 IPC capability 声明这条边界一旦被突破远程网页就能以桌面应用的身份调用受限能力。三处实现印证1. 命令输入做语义边界校验。src-tauri/src/app/invoke.rs 中集中了应用的全部#[tauri::command]位于 L103、L180、L193、L200、L208、L214、L221、L237、L248 共九处。以 macOS Dock 角标的命令为例invoke.rs#L17-L37 展示了“语义边界”的校验方式——不是仅做类型检查而是约束取值域const MAX_BADGE_COUNT: i64 99_999; const MAX_BADGE_LABEL_CHARS: usize 16; fn normalize_badge_count(count: Optioni64) - Optioni64 { count.filter(|n| (1..MAX_BADGE_COUNT).contains(n)) } fn normalize_badge_label(label: Optionstr) - ResultOptionString, String { let Some(label) label.map(str::trim).filter(|label| !label.is_empty()) else { return Ok(None); }; if label.chars().count() MAX_BADGE_LABEL_CHARS { return Err(format!(Badge label must be {MAX_BADGE_LABEL_CHARS} characters or fewer)); } Ok(Some(label.to_owned())) }Option输入归一化、闭区间范围约束、超长/非法值返回Err而非 panic——正是铁律 1 在 Rust 侧的体现。2. capability 最小化。Tauri v2 的权限模型通过 src-tauri/capabilities/default.json 声明每个窗口可触达的插件与命令集合。规则要求该集合保持“精确到刚好覆盖所需操作”即不为打包的网页开放超出运行时功能需要的能力面。3. IPC 异步化。规则要求长时间运行的命令保持异步从源码结构看invoke.rs中的命令函数普遍以async fn ... - Result..., String形态返回错误字符串而非抛出 panic配合 Tauri 的异步命令机制这样页面侧即使发起慢命令也不会卡死应用主循环——而卡死主循环的正是远程页面可能达到的最坏后果之一。小结一套可对照的工程检查清单把.claude/rules/rust.md的约定浓缩成一张改动前的自检清单每条都附仓库内可验证的依据检查项依据文件用户可达路径无panic!/unwrap()/expect()错误用?上抛规则原文 src-tauri/src/app/invoke.rs 的Result返回范式静默吞错至少logger.warn状态行走logger.infobin/options/logger.ts、bin/utils/output.ts#L56-L67可预期失败抛PakeError {code, hint}退出码按契约映射bin/utils/error.ts、bin/utils/output.ts#L19-L27--json模式 stdout 只输出一个 JSON子进程输出重定向 stderrbin/utils/shell.ts#L11-L19失败引导基于调用方结构化事实如target appimage不 greperror.messagebin/builders/BaseBuilder.ts#L255-L295配置一律走PakeTauriConfig禁止any配置袋bin/types.ts#L213-L241新增窗口选项四处代码 schema 文档缺 schema 由测试兜底tests/unit/config-file.test.ts、schema/pake.schema.json#[tauri::command]输入做语义边界校验、capability 最小化、IPC 保持异步src-tauri/src/app/invoke.rs#L17-L37、src-tauri/capabilities/default.json这套规则的共同指向只有一个Pake 的输出物是面向最终用户的桌面应用其构建器CLI和运行时壳Tauri都必须做到——错误永远以结构化、可预期的形式呈现配置永远有类型契约兜底来自网页的一切都按不可信输入对待。【免费下载链接】Pake Turn any webpage into a desktop app with one command.项目地址: https://gitcode.com/GitHub_Trending/pa/Pake创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Pake 的 Rust/Tauri 工程铁律：CLI 错误处理、配置类型安全与 IPC 信任边界
Pake 的 Rust/Tauri 工程铁律CLI 错误处理、配置类型安全与 IPC 信任边界【免费下载链接】Pake Turn any webpage into a desktop app with one command.项目地址: https://gitcode.com/GitHub_Trending/pa/Pake本文基于 Pake 仓库中的规则文件.claude/rules/rust.md展开系统讲解该项目的三组核心工程约定面向用户的错误处理规范、Tauri 配置的类型安全要求以及“打包进应用的远程页面不可信”这一 Tauri 信任边界原则。读完本文你可以掌握 Pake 中PakeError、--json机器模式、PakeTauriConfig类型体系的完整落地方式并能理解为什么 Pake 强调“永远不要靠 grep 错误消息来分类构建失败”。规则文档的定位Pake 特有的 Rust Tauri 约束Pake 是一个“一条命令把任意网页打包成桌面应用”的工具Turn any webpage into a desktop app with one command。它的技术栈分为两层CLI 构建层TypeScript位于bin/目录负责解析参数、合并配置、驱动 Tauri/cargo/linuxdeploy 等子进程完成打包运行时壳层Rust Tauri位于src-tauri/目录被打包进每一个生成的桌面应用负责窗口管理、导航保护、IPC 命令等运行时行为。.claude/rules/rust.md开篇即声明了自身边界标准 Rust 卫生?优先于unwrap()、cargo clippy零告警、提交前cargo fmt默认成立不再重复dist/cli.js的重建规则、CN 镜像策略、平台敏感规则Linux/Wayland WebKit 合成、AppImage 警告噪音、--incognito、内嵌 WebView OAuth 等都放在 AGENTS.mdCurrent Risk Areas / Network Mirror Behavior 章节本文不重复。也就是说这份规则文件聚焦的是三件跨两层技术栈都必须守住的 Pake 特有约定错误处理、配置类型、Tauri 信任边界。下面逐一拆解并用仓库源码印证每条规则的落地实现。错误处理四条铁律与它们的源码实现规则原文对错误处理提出了四条要求每一条都能在bin/目录下找到对应的实现证据。铁律 1用户可达路径上禁止panic!/.unwrap()/.expect()在用户可达的路径上CLI 选项解析、配置加载、事件处理器、IPC 命令不得使用panic!/.unwrap()/.expect()应使用?向上抛出并给出清晰信息。这条规则横跨两层代码。Rust 侧对应src-tauri/中被打包进用户应用的代码——一旦用户在某个打包出来的应用里触发 IPC 命令崩溃整个桌面应用直接挂掉这比 CLI 报错严重得多。TypeScript 侧对应 CLI 的任何用户交互路径。铁律 2静默吞错必须至少升级为logger.warnTS 中的catch {}或 Rust 中的let _ ...这类静默吞错至少要通过logger.warn把真实错误暴露出来。注意logger.warn同时会流入--json结果的warnings数组状态行应使用logger.info。这里的细节很值得展开。Pake 的日志封装在 bin/options/logger.ts 中基于loglevelchalk实现info/debug/error/warn/success五个方法。而在机器模式下--jsonbin/utils/output.ts#L56-L67 中的enableMachineMode()会接管 loglevel 的methodFactory所有日志被重定向到 stderr其中warn级别的条目会被额外捕获进capturedWarnings最终进入 JSON 结果的warnings数组。这意味着logger.warn和logger.info的语义分界不是随意偏好而是契约warn会被机器读到进入warnings: string[]info只作为人类可读的状态行。规则文档特意点出这一点bin/builders/BaseBuilder.ts#L240-L244 中的注释也是同一逻辑// Show static message to keep the status visible. Info, not warn: warn // entries feed the --json warnings array and this is a status line. logger.info(✸ Building app...);--json模式下最终输出的结构定义在 bin/utils/output.ts#L35-L47export interface PakeJsonResult { ok: boolean; name: string | null; platform: NodeJS.Platform; arch: string | null; outputs: BuildArtifact[]; warnings: string[]; // ← logger.warn 的捕获结果 error: { code: PakeErrorCode; message: string; hint: string | null; } | null; }铁律 3可预期的失败抛PakeError {code, hint}退出码稳定可映射可预期的 CLI 失败应抛出带{code, hint}的PakeError定义于bin/utils/error.tscode映射到稳定的退出码和--json错误对象普通的Error则由bin/cli.ts按构建阶段build phase分类。实现见 bin/utils/error.ts#L12-L35export class PakeError extends Error { readonly isUserError true; readonly code?: PakeErrorCode; // INVALID_INPUT | ENV_MISSING | BUILD_FAILED | NETWORK | UNEXPECTED readonly hint?: string; // 给用户的下一步建议 // ... }退出码契约写死在 bin/utils/output.ts#L19-L27code退出码含义INVALID_INPUT2输入不合法BUILD_FAILED/NETWORK3构建或网络失败ENV_MISSING4缺少运行环境如未装 RustUNEXPECTED1未预期错误bin/cli.ts顶层的classifyError逻辑遵循“带显式code的PakeError优先于阶段默认值”的原则如果抛出的不是PakeError则按当前所处阶段input→prepare→build见bin/cli.ts中phase变量的推进套用阶段默认code。这样 CI/Agent 可以仅凭退出码判断失败类别不需要解析终端文本。一个真实用例BaseBuilder.prepare()检测不到 Rust 且处于非交互模式时抛出new PakeError(Rust required to package your webapp., { code: ENV_MISSING, hint: Install Rust via https://rustup.rs, then rerun the same command. })见 bin/builders/BaseBuilder.ts#L135-L157。铁律 4--json机器模式下 stdout 只属于唯一的 JSON 结果机器模式下 stdout 被唯一的 JSON 结果独占。bin/中任何地方都不得console.log/process.stdout.write子进程 stdout 由shellExec重定向到 stderr。这条规则的实现分两处日志层enableMachineMode()将所有 loglevel 输出改写到console.errorstderr并关闭 chalk 颜色保证 stdout 干净可JSON.parse子进程层bin/utils/shell.ts#L11-L19 中execa的 stdio 配置为stdout: isMachineMode() ? process.stderr : inherit——交互模式实时透传linuxdeploy、cargo、npm的输出即时可见机器模式重定向到 stderr。shellExec陷阱为什么不能靠 greperror.message分类构建失败规则文档中最有分量的一段是shellExec用stdio: inherit运行子进程因此它们的输出linuxdeploy、cargo、npm永远不会进入error.message只有失败的命令行会进入。不要通过 greperror.message来分类构建失败——那匹配到的是命令而不是诊断信息。失败引导应基于调用方持有的结构化事实例如target appimage。责任方bin/utils/shell.tsbin/builders/BaseBuilder.ts。这个约束的根源在 bin/utils/shell.ts#L25-L40stdio: inherit意味着子进程诊断直接流到终端execa抛出的error.message里只包含命令字符串本身。所以“从错误文本判断失败原因”这条路在架构上就是死的。正确的做法示范就在 bin/builders/BaseBuilder.ts 的 Linux AppImage 失败处理中调用方天然持有结构化事实isLinuxAppImage process.platform linux target appimageL255-L256于是它第一次构建失败后基于该事实自动用NO_STRIP1重试一次glibc 2.38 的 strip 兼容问题是 AppImage 最常见的失败原因重试仍失败时把APPIMAGE_FAILURE_GUIDANCEL34-L53追加到错误消息中——这份引导不声称知道具体原因注释明确写道 “we cannot name the exact cause”而是列出全部已知原因与修复命令gdk-pixbuf loaders 缺失给出 Arch/Debian/Fedora 三种发行版的安装命令、Docker 容器缺/dev/fuse时的启动参数、以及退路方案pake url --targets deb详细指南指向 docs/faq.md。这个设计是“铁律 3 铁律 4”的合力产物hint/引导文本承担给人类的下一步建议退出码与code承担给机器的分类而具体诊断则留在终端由用户自行阅读——三层各司其职。配置类型安全禁止tauriConf: any规则原文不允许tauriConf: any或其他无类型配置袋。使用PakeTauriConfig。 窗口选项分布在bin/helpers/cli-program.ts、bin/types.ts、bin/defaults.ts、bin/helpers/merge.ts四处。新增一个选项意味着要同时改这四个文件再加上schema/pake.schema.json和docs/cli-usage*.md。漏掉任何一个都是回归其中 schema 那半边由tests/unit/config-file.test.ts兜底。这条规则针对的是 Pake 的工作流本质CLI 选项最终会被合并写进一个临时的src-tauri/.pake/tauri.conf.json供 Tauri 构建使用见 bin/builders/BaseBuilder.ts#L475-L483。如果配置是无类型的any袋任何一个拼写错误都只会表现为“选项悄悄不生效”而不是编译错误。类型体系定义在 bin/types.ts核心有三个接口PakeTauriConfigL213-L241对 Tauri 配置结构的类型化描述包含productName、identifier、version、mainBinaryName、pake: PakeConfig、bundle含各平台细分字段等PakeConfig/WindowConfigL171-L211Pake 自有配置块的结构WindowConfig的字段hide_title_bar、always_on_top、internal_url_regex、zoom、min_width等与 CLI 选项一一对应PakeCliOptionsL4-L159全部 CLI 选项的完整类型定义每个字段带默认值注释如width默认 1200、zoom默认 100、bundle默认 true 等可作为参数速查表。运行时装配逻辑在 bin/helpers/tauriConfig.ts它从 npm 包目录读取src-tauri/pake.json和tauri.conf.json再按process.platform选择tauri.windows.conf.json/tauri.macos.conf.json/tauri.linux.conf.json之一仅取其中的bundle与app.trayIcon平台差异字段合并出最终基线配置。“新增选项五处必改”清单cli-program.ts解析 types.ts类型 defaults.ts默认值 merge.ts合并 schema/pake.schema.json校验 docs/cli-usage*.md与docs/cli-usage_CN.md文档本质上是一张变更影响面清单tests/unit/config-file.test.ts 负责在测试中拦截“schema 忘了加字段”这一类最常见的遗漏。Tauri 信任边界打包进去的远程页面是不可信输入规则原文三条要求打包进应用的远程页面是不可信的。每个#[tauri::command]的输入都必须做语义边界校验远程页面的 capability 保持“恰好够用”长时间运行的 IPC 保持异步让页面代码无法阻塞应用主循环。为什么这是 Pake 必须单独写进规则的一条因为 Pake 打包的恰恰是任意的第三方网页——任何用户都可以对任何 URL 执行pake url。生成的应用里WebView 加载的页面代码与 Rust 侧的 Tauri 命令之间只隔一层 IPC capability 声明这条边界一旦被突破远程网页就能以桌面应用的身份调用受限能力。三处实现印证1. 命令输入做语义边界校验。src-tauri/src/app/invoke.rs 中集中了应用的全部#[tauri::command]位于 L103、L180、L193、L200、L208、L214、L221、L237、L248 共九处。以 macOS Dock 角标的命令为例invoke.rs#L17-L37 展示了“语义边界”的校验方式——不是仅做类型检查而是约束取值域const MAX_BADGE_COUNT: i64 99_999; const MAX_BADGE_LABEL_CHARS: usize 16; fn normalize_badge_count(count: Optioni64) - Optioni64 { count.filter(|n| (1..MAX_BADGE_COUNT).contains(n)) } fn normalize_badge_label(label: Optionstr) - ResultOptionString, String { let Some(label) label.map(str::trim).filter(|label| !label.is_empty()) else { return Ok(None); }; if label.chars().count() MAX_BADGE_LABEL_CHARS { return Err(format!(Badge label must be {MAX_BADGE_LABEL_CHARS} characters or fewer)); } Ok(Some(label.to_owned())) }Option输入归一化、闭区间范围约束、超长/非法值返回Err而非 panic——正是铁律 1 在 Rust 侧的体现。2. capability 最小化。Tauri v2 的权限模型通过 src-tauri/capabilities/default.json 声明每个窗口可触达的插件与命令集合。规则要求该集合保持“精确到刚好覆盖所需操作”即不为打包的网页开放超出运行时功能需要的能力面。3. IPC 异步化。规则要求长时间运行的命令保持异步从源码结构看invoke.rs中的命令函数普遍以async fn ... - Result..., String形态返回错误字符串而非抛出 panic配合 Tauri 的异步命令机制这样页面侧即使发起慢命令也不会卡死应用主循环——而卡死主循环的正是远程页面可能达到的最坏后果之一。小结一套可对照的工程检查清单把.claude/rules/rust.md的约定浓缩成一张改动前的自检清单每条都附仓库内可验证的依据检查项依据文件用户可达路径无panic!/unwrap()/expect()错误用?上抛规则原文 src-tauri/src/app/invoke.rs 的Result返回范式静默吞错至少logger.warn状态行走logger.infobin/options/logger.ts、bin/utils/output.ts#L56-L67可预期失败抛PakeError {code, hint}退出码按契约映射bin/utils/error.ts、bin/utils/output.ts#L19-L27--json模式 stdout 只输出一个 JSON子进程输出重定向 stderrbin/utils/shell.ts#L11-L19失败引导基于调用方结构化事实如target appimage不 greperror.messagebin/builders/BaseBuilder.ts#L255-L295配置一律走PakeTauriConfig禁止any配置袋bin/types.ts#L213-L241新增窗口选项四处代码 schema 文档缺 schema 由测试兜底tests/unit/config-file.test.ts、schema/pake.schema.json#[tauri::command]输入做语义边界校验、capability 最小化、IPC 保持异步src-tauri/src/app/invoke.rs#L17-L37、src-tauri/capabilities/default.json这套规则的共同指向只有一个Pake 的输出物是面向最终用户的桌面应用其构建器CLI和运行时壳Tauri都必须做到——错误永远以结构化、可预期的形式呈现配置永远有类型契约兜底来自网页的一切都按不可信输入对待。【免费下载链接】Pake Turn any webpage into a desktop app with one command.项目地址: https://gitcode.com/GitHub_Trending/pa/Pake创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考