本方主要介绍在编译solana程序时，提示 rustc 版本号过低无法编译通过的问题。

问题描述

在参考官方教程 https://github.com/solana-developers/program-examples/tree/main/basics/favorites/native 在本地执行命令

➜  native git:(main) ✗ cargo build-sbf --manifest-path=./program/Cargo.toml --sbf-out-dir=./program/target/so

报错

➜  native git:(main) ✗ cargo build-sbf --manifest-path=./program/Cargo.toml --sbf-out-dir=./program/target/so
error: package `solana-program v2.1.7` cannot be built because it requires rustc 1.79.0 or newer, while the currently active rustc version is 1.75.0-dev
Note that this is the rustc version that ships with Solana tools and not your system's rustc version. Use `solana-install update` or head over to https://docs.solanalabs.com/cli/install to install a newer version.
Either upgrade to rustc 1.79.0 or newer, or use
cargo update [email protected] --precise ver
where `ver` is the latest version of `solana-program` supporting rustc 1.75.0-dev

翻译过来就是使用的 rustc 版本号过低，至少需要1.9.0 或更高才可以，这里的rustc版本与并非本地安装的rustc版本号。

在上一篇《了解 Solana 中ATA账户与普通账户的关系》中，我们介绍了在Solana中，ATA账户与Token Account 的区别，其中在浏览器记录查看 user2 用户详细的时候，发现它与前两个账户有所区别，它没有 Owner 属性，这在正常情况下是不应该出现的，所以，我们来分析一下，为什么Token Account没有 Owner 属性？

在 Soalna中，默认情况下所有的新账户都属于 System Program，也只有系统程序拥有的账户才可以作为交易费用支付者（也就是账户里必须的原生币sol）。

因此示例中正常的 Token Account

异常账号

出现我这种情况主要有两种情况：

1. 交易还在处理中，尚未完成，这种情况下一般只需要等待一会就会正常。
2. 账户未被初始化，需要初始化后才恢复正常。

常见的初始化方法：

1. 空投原生币
2. 转账原生币
3. 通过 SystemProgram.createAccount 创建账号·

在上篇文章里，我们为了演示转账记录，对 payer 和 user1 用户都进行了空投，在空投时将自动对账户进行初始化操作，因此在浏览器里显示的 Owner 是正常状态，但对于 user2 用户，由于没有进行初始化，所以没有 Owner 属性。

那么这里有两个疑问。

第一个疑问：为什么没有初始化，仍可以根据这个账户创建ATA账号呢？

其实在 Solana 中，对于账户来说它只要是一个合法的 address 地址即是一个效的账户，它和其是否初始化无关。

第二个疑问：既然没有初始化，那它怎么会在浏览器里显示呢？

原理和上面的一样，它只是一个地址。理论上所有有效的地址都可以在区块链浏览器上访问，唯一的区别是这个地址是否有包含一些数据信息。当你通过浏览器查看时，如果账户有相关数据信息的话，它会将这些数据信息显示出来；如果没有数据信息，则不会显示。

而我们的 user2 用户是没有数据信息，所以它根本不会显示 Owner 属性。

验证代码

这里为了提供演示，给出一下代码：

import {
  Connection,
  PublicKey,
  Keypair,
  LAMPORTS_PER_SOL,
  SystemProgram,
} from "@solana/web3.js";

async function main() {
  const connection = new Connection("http://localhost:8899", "confirmed");
  const account = Keypair.generate();

  console.log("账户地址:", account.publicKey.toBase58());

  // 1. 创建后（未初始化）
  console.log("\n创建后（未初始化）:");
  let accountInfo = await connection.getAccountInfo(account.publicKey);
  console.log("账户是否存在:", accountInfo !== null); // false
  console.log("账户信息:", accountInfo); // null

  // 2. 空投 SOL（初始化过程）
  const airdropSig = await connection.requestAirdrop(
    account.publicKey,
    LAMPORTS_PER_SOL,
  );
  await connection.confirmTransaction(airdropSig);

  // 3. 初始化后
  console.log("\n初始化后:");
  accountInfo = await connection.getAccountInfo(account.publicKey);
  console.log("账户是否存在:", accountInfo !== null); // true
  console.log("账户信息:", {
    owner: accountInfo?.owner.equals(SystemProgram.programId)
      ? "System Program"
      : accountInfo?.owner.toBase58(),
    lamports: accountInfo?.lamports,
  });
}
main().catch(console.error);

程序输出结果：

本文主要通过示例让大家理解在 Solana 中 ATA 账户与普通账户的关系。

目的

主篇内容目的是为了让开发者加深对 solana 中 Account 这一概念的理解，同时搞清楚 关联代币账户(ATA) 在 Solana 开发中的使用场景和用法，以及在多个账户之间的交易和手续费扣除情况。

本篇实现源码会在 github.com/cfanbo/solana-repos/ 中找到。

这里用到的一些api 函数可以在以下地址找到：

• @solana/web3.js 用户实现通过 Solana JSON RPC API 与 Solana 网络上的帐户和程序进行交互。
• @solana/spl-token 用于实现与 SPL Token 和 Token-2022 程序交互。

本文通过脚本实现 SPL Token 标准功能，并不需要调用已创建好的智能合约，因此不需要 programId.

设置网络环境

➜  my-solana-program git:(master) ✗ solana config get
Config File: /Users/sxf/.config/solana/cli/config.yml
RPC URL: https://api.devnet.solana.com
WebSocket URL: wss://api.devnet.solana.com/ (computed)
Keypair Path: /Users/sxf/.config/solana/id.json
Commitment: confirmed

默认情况下，当根据教程 https://solana.com/zh/docs/intro/installation 安装好后，默认环境就是开发环境。不过这里为了方便，我使用了本地作为开发环境。

➜  my-solana-program git:(master) ✗ solana config set --url localhost
Config File: /Users/sxf/.config/solana/cli/config.yml
RPC URL: http://localhost:8899
WebSocket URL: ws://localhost:8900/ (computed)
Keypair Path: /Users/sxf/.config/solana/id.json
Commitment: confirmed

➜  my-solana-program git:(master) ✗ solana config get
Config File: /Users/sxf/.config/solana/cli/config.yml
RPC URL: http://localhost:8899
WebSocket URL: ws://localhost:8900/ (computed)
Keypair Path: /Users/sxf/.config/solana/id.json
Commitment: confirmed

在本地启动模拟器服务

在看 Solidity 文档 https://solidity-by-example.org/app/erc20/ 时，对于其中一段授权额的编码逻辑有点不明白，经过一翻查找资料才算彻底搞明白它的操作逻辑，这里特意将其记录一下。

ERC20代币标准

在ERC20代币标准(https://eips.ethereum.org/EIPS/eip-20) 中定义了一系列的接口方法

interface IERC20 {
  function totalSupply() external view returns (uint256); // 返回代币总供应量。
  function balanceOf(address account) external view returns (uint256); // 查询某个账户的代币余额。
  function transfer(address recipient, uint256 amount) external returns (bool); // 从调用者账户向其他地址转移代币。
  function allowance(address owner, address spender) external view returns (uint256); // 查询某地址被授权从另一个账户转移的额度。
  function approve(address spender, uint256 amount) external returns (bool); // 授权某地址从调用者账户转移一定数量的代币。
  function transferFrom(address sender, address recipient, uint256 amount) external returns (bool); // 由授权地址代表其他地址转移代币。
}

除此之外还有两个事件，虽然不是必须的，但还是强烈建议实现，方便以后排查错误。 注意上面的接口并不表示一定全部实现，需要根据场景来做判断。有些函数如 totalSupply() ，如果使用声明变量 uint256 public totalSupply; 的方式的话，将自动生成对应的getter函数,因此就没有必要手动再实现了。

转账方式

在ERC20标准中，转账有两种方式：

• transfer 转账 常见的转账方式，适应于普通场景，假设 账户A 转币给 账户B，调用这个底层函数会直接从调用者的账户中扣除代币，并将其转账到指定的接收者。
• transferFrom 转账 这是另一种转账方式，通常用于需要授权的情况下，允许第三方代币持有者转账代币。此方法需要先通过 approve 授权一个代理账户（spender），表示代理可以从发送者账户中提取一定数量的代币（下方称为 X）。

大概步骤：

1. 首先 账户A给合约账户X一定的授权额度(最高)，表示 合约X 可以从 A账户里划走 amount 数量币，这个由 账户A 主动调用函数 approve()完成
2. 然后合约 账户X 才可以将币转给 账户B, 当然转账前必须检查授权额度是否足够才可以，如果足够则对两个账户的币进行加减，这个由合约X 调用函数 transferFrom 完成

可以看到相比普通转账，transferFrom 转账多了一个中间代理人而已，其它并没有什么不同。

IDE 插件 AI Translate 经过几个小版本的迭代，目前已经支持市面上主流的 LLM 服务提供商，主要有以下几个服务提供商：

• OpenAI
• Anthropic
• DeepL
• 智谱 GLM
• 字节跳动
• DeepSeek
• Alibaba
• GitHub
• Gemini
• Ollama

除此之外，还有两个智能体服务商

• 阿里云百炼
• 扣子

基本已经满足了大多数开发者的翻译需求。

下载地址：

• JetBrains: https://plugins.jetbrains.com/plugin/25313-ai-translate
• VSCode: https://marketplace.visualstudio.com/items?itemName=cfanbo.ai-translate

特别是最近对 Ollama 的支持，允许用户使用本地的大模型提供服务，无需像其它几个 provider 一样，还需要注册会员和身份主证。只需要填写一个 URL 地址即可使用，非常的方便。

由于目前使用的 prompt 是统一的，因此不同 provider 的翻译效果可能不一样，后续有可能提供针对不同 provider 或 model 自定义prompt 的功能。

如果你想免费使用 OpenAI 模型的话，推荐注册 https://gh.io/models 服务，它提供了 GPT_4o、GPT_4o mini、o1-mini、o1-preview 模型，甚至还提供了两个 Embedding 模型，这一切都是免费的。Github 还为每个用户提供了一个 codesapce ，它是一个远程服务器环境，可以直接作为免费的试验环境，很值得推荐的。

目前不清楚新用户注册是否还需要审核。我是前几个月前在产品出来之前申请的，当时是需要等待审核的。

在Zed IDE中，默认只支持以下几种 providers :

• Zed AI (Configured by default when signed in)
• Anthropic
• GitHub Copilot Chat 1
• Google AI 1
• Ollama
• OpenAI

这对于国内开发者来说，由于政策原因，想使用起来可能需要借助一些科学上网的方法，这就有点麻烦了。另外国内几个大模型公司也都提供了一定的免费额度的 tokens，如果可以在 Zed 里集成国内几家的大模型，也是一个不错的主意。

几个月前试图通过自定义Endpoint 的方法绕过官方对使用区域的限制，但一直没有成功。今天重新试了一下仍是无效，本想打算在官方仓库里开发一个自定义provider的功能，就是感觉着有点麻烦，另外更担心个人电脑过旧，编译是一个大问题，于是重新在issue里找到了一个解决办法 https://github.com/zed-industries/zed/pull/13276，就是设置起来有点麻烦。

本文将其设置方法整理如下。

配置 settings.json

首先配置 settings.json 里的 assistant 和 language_models 。

这里以 DeepSeek 为例，完整的内容如下

{
  "assistant": {
    "default_model": {
      "provider": "openai",
      "model": "deepseek-chat"
    },
    "enabled": true,
    "provider": {
      "name": "openai",
      "default_model": {
        "custom": {
          "max_tokens": 32000,
          "name": "deepseek-chat"
        }
      },
      "available_models": [
        {
          "custom": {
            "name": "deepseek-chat",
            "max_tokens": 32000
          }
        },
        {
          "custom": {
            "name": "deepseek-code",
            "max_tokens": 32000
          }
        }
      ],
      "api_url": "https://api.deepseek.com/v1"
    },
    "version": "2"
  },
  "language_models": {
    "openai": {
      "version": "1",
      "api_url": "https://api.deepseek.com/v1",
      "available_models": [
        {
          "provider": "openai",
          "name": "deepseek-chat",
          "max_tokens": 32000
        },
        {
          "provider": "openai",
          "name": "deepseek-code",
          "max_tokens": 32000
        }
      ]
    }
  },
}

上面有些配置项看起来是重复的，这个不用管它，不要做任何删除操作，将其复制到 settings.json 文件里代替原来的配置项即可。其中 assistant.default_model 里的值会在后面选择不同模型时动态的更新。

AI Translate 是一款基于LLM实现的IDE专用翻译插件，主要为开发人员在查看项目源码时，可以快速对一些代码英文注释进行中文翻译，这对于英文有些弱的同学很有帮助，下面讲一下为什么开发这款IDE插件，以及它比其它同类翻译插件有什么好处。

为什么开发这款翻译插件

在以前使用IDE看项目源码时，经常遇到长段的英文段落注释信息，理解起来经常会吃力。当时找了一些翻译插件，但都感觉多多少少有些缺陷。

主要表现以下几点：

1. 翻译质量差，有些翻译软件可能将一些专业术语翻译成了其它名词，整体翻译后的语句读起来很让人头疼
2. 由于在源码文件里，多数源码说明 信息都是以注释方式出现的，多数翻译软件无法做到忽略注释符后连贯起来翻译。
3. 目前市面比较好用的翻译插件“沉浸式翻译”，可惜只支持浏览器，并不支持IDE

曾有一段时间的做法是手动从IDE里复制信息、删除注释符、重新整理段落，再到网页翻译里进行翻译，有时翻译的效果不太好，可能同时会用两个翻译软件。

去年看kubernets源码时，再次被折腾一番，当时花了两三个小时开发了一款基于chrome浏览器的插件，主要实现功能是在软件翻译前，将注释符移除和重新整理段落，这样效果稍微好一些，毕竟节省了不少时间，只是仍未解决从IDE复制代码再进行翻译的问题。

前段时间看ETCD源码时，再次被这个折腾一番，最终还是决定开发一款IDE翻译插件，正好可以使用LLM来解决以前传统翻译软件翻译质量不太好的问题。主要改进两点，一个是有一些专业术语被翻译成了普通的单词，读起来很无语；另一个是有些单词没有必要翻译成中文，保持原样即可，但翻译软件硬是翻译成了中文。

调研了几款目前市面上流行的插件，好像都不支持IDE的这种翻译功能。

1. 沉浸式阅读插件功能十分强大，即可以使用传统翻译软件，也可以使用LLM进行翻译，只可惜的是当前只有浏览器插件，并不支持IDE的翻译功能。
2. Alibaba的“通义灵码”IDE插件，功能也十分强大，在IDE工具里直接集成LLM，实现用户交互，可惜的只竟然不支持翻译功能

既然没有轮子，那就造一个吧，插件开发也挺简单的，也花不了太多的时间。

JetBrains IDE 插件开发太麻烦了，每次都等于开启两个窗口，内存和CPU几乎吃完了，调试一次运气不好的话，花1个小时也正常，相对来说vscode 插件开发就容易的多了。

实现原理

插件的功能很简单，只做一件事：将用户在IDE里选择的文本信息发送到LLM提供的API接口，然后再将接口返回的信息在IDE控制终端输出。

至于这个翻译功能主要是在LLM应用端通过配置 prompt 来实现的，告诉LLM你是一个技术开发人员，熟练各种开发语言，将收到的信息整理后，翻译中文并输出就可以了。

在LLM端可以配置多种功能，如是否启用“记忆”功能和一些插件，以实现更多的功能。

插件功能

因此可以自定义prompt实现类似的功能，如 程序员变量命名、SQL解释、代码解释等。

如果IDE插件“通义灵码”有翻译功能，则完全满足当前需求了，遗憾就是没有这个翻译功能，这也正是开发这个插件的原因。

支持哪些IDE

目前主要支持 VSCode 编辑器和 JetBrains 公司的IDE产品。

• VSCode：https://marketplace.visualstudio.com/items?itemName=cfanbo.ai-translate (GitHub)
• JetBrains Marketplace: https://plugins.jetbrains.com/plugin/25313-ai-translate (GitHub)

使用教程

使用插件前，需要填写通义千问应用的 APPID 和 APPKEY，如果还没有开通的话，需要开通后(https://bailian.aliyun.com/)，创建应用后可获取这两项信息。

使用方法很简单，共两步：

1. 在 IDE 里选择要翻译的内容，一般指注释信息
2. 右键选择“AI 翻译“ 菜单即可，也可以使用快捷键 Ctrl+Alt+T

如果使用的是 JetBrains 系统IDE的话，注意快捷键是否有冲突，可以自行设置快捷键。

为了实现翻译的功能，还需要设置应用的prompt ，告诉LLM要实现翻译的功能，这里可以参考github仓库里的 README.md 文档，用户也可以根据需要进行调整。

今年又一次重新学习RUST这门编程语言，并从零开发了一个kv存储系统 minKV，慢慢的越来越有感觉了。

本篇主要将日常学习中收集的一些入门教程进行一下汇总，希望对于一些想学习这门开发语言的同学有所帮助。

下面教程按照推荐顺序，由浅到深依次列出。以下内容将不定期的更新，请自行收藏。 如果您有更多好的教程的话，也可以在评论区列出，大家相互学习。

入门教程

1. Rust 程序设计语言 https://doc.rust-lang.org/book/ / (中文版)

   官方教程，强烈推荐，同时还有非官方翻译的中文版。遗憾的是这个教程有许多概念介绍的都有点不清不楚，只能通过下方的一些资料自行补习。

2. https://play.rust-lang.org/ 在线 RUST 程序 Playground，类似golang的 Playground，非常的方便

3. Rust Language Cheat Sheet 看完官方的教程后，紧接着就看这篇，先了解一些内存布局，后面再看其它教程就更容易理解了

4. The Cargo Book Cargo 是RUST 中的包管理工具，开发必备工具

5. https://rust-lang-nursery.github.io/rust-cookbook/ / (Rust Cookbook 中文版)

6. Rust语言圣经(Rust Course)

7. rust-by-example 在实践中学 Rust

8. Rust By Practice Rust语言实战 / (中文版)

9. 100 Exercises To Learn Rust

10. Comprehensive Rust 由Google 的 Android 团队开发的免费 Rust 课程

11. Tour of Rust

进阶教程

1. Tokio 异步运行时 强烈推荐 ！！！一个强大的运行时，目前市场占有绝对的优势，每个RUST必学
2. Command Line Applications in Rust 开发命令行工具必具。有一个 clap 的crate，它有 Builder 和 Derive 两种用法，本人在开发 gitig 和 minkv 两个项目时分别使用到了这两种用法，推荐使用 Derive 用法，比较简单易理解
3. The Rustonomicon
4. Rust 宏小册
5. Rust and WebAssembly WASM开发手册
6. 深入RUST标准库 国内同学翻译的，不过是两年前翻译的，可能与现在使用的标准库有些差别，不过作为阅读标准库的参考书也不错

开发规范

• Rust API Guidelines
• PingCAP Style Guide

视频教程

如果习惯看视频学习的话，可以看以下列出的一些B站UP主视频，前两个UP主的视频与一些教程是同步的，以视频的形式重新对教程进行了讲解。

上一篇 我们介绍了一些错误处理的最基本的用法，主要是指对 panic! 、unwrap、expect 和 ? 这些宏或函数的介绍。但这仅仅是一些最基本的处理方法，对于自定义错误这一块并没有做任何介绍。

实际开发中可能默认的错误类型，并无法满足我们的业务需求，这时一般需要通过定义自己的错误类型来实现。在rust中错误类型是通过 enum 枚举定义的，对此官方文档也做了一些简介，本文主要介绍一些业务开发过程中对错误的处理方案，当然主要是一些最基本的用法。

自定义 Error

在 Rust 中，自定义错误类型是一种常见的类型，特别是当你需要提供比标准错误类型更具体的错误信息时。Rust 中的错误处理是通过 Result 和 Error trait 来实现的。以下是如何实现一个自定义错误的示例：

1. 定义一个错误枚举类型。
2. 实现 std::fmt::Display 为自定义错误提供用户友好的错误信息。
3. 实现 std::error::Error trait，这通常是通过派生 Error trait 来完成的。

下面是一个简单的示例：

use std::fmt;
use std::error::Error;

// 定义一个自定义错误枚举
#[derive(Debug)]
enum MyError {
    Io(std::io::Error), // 包装标准库的I/O错误
    NotFound(String),    // 一个未找到的错误，包含一个描述信息
    InvalidInput(String), // 无效输入错误，包含一个描述信息
}

// 为自定义错误实现 Display trait
impl fmt::Display for MyError {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        match *self {
            MyError::Io(ref err) => write!(f, "IO error: {}", err),
            MyError::NotFound(ref desc) => write!(f, "Not found: {}", desc),
            MyError::InvalidInput(ref desc) => write!(f, "Invalid input: {}", desc),
        }
    }
}

// 为自定义错误实现 Error trait
impl Error for MyError {
    fn source(&self) -> Option<&(dyn Error + 'static)> {
        match *self {
            MyError::Io(ref err) => Some(err),
            _ => None,
        }
    }
}

// 使用自定义错误类型的例子
fn do_something_that_might_fail(input: &str) -> Result<(), MyError> {
    if input.is_empty() {
        Err(MyError::InvalidInput("Input cannot be empty".to_string()))
    } else {
        // 假设这里有一些可能失败的操作
        Ok(())
    }
}

fn main() {
    match do_something_that_might_fail("") {
        Ok(_) => println!("Success!"),
        Err(e) => println!("Error occurred: {}", e),
    }
}

在这个示例中，MyError 是一个自定义的错误枚举，它包含了几种可能的错误情况。我们为它实现了 Display 和 Error trait，这样就可以在需要的时候提供错误信息，并且可以与其他错误处理机制无缝集成。在 main 函数中，我们展示了如何使用 do_something_that_might_fail 函数，它可能会返回我们的自定义错误。

gitig 是一款基于 https://github.com/github/gitgnore 仓库开发的.gitignore 客户端CLI 管理工具，也是每个开发者必不可少的提高工作效率的必具工具。

它基于官方仓库 https://github.com/github/gitgnore 丰富的 .gitignore 数据源，帮助开发者快速实现添加各类开发项目的git版本控制忽略文件清单。

开发背景

工作中，经常需要开发各类项目，如基于 vscode 编写 rust 项目，这时为了方便进行Git管理控制，有些项目文件可能并不需要提交到git仓库，需要将一些文件写入 .gitignore 文件进行忽略。

如果手动编辑 .gitignore文件可能有些麻烦，另外也能会有一些文件项被遗忘或写错，这时如果有一些工具可以将行业能用的忽略配置项一键写入 .gitignore 文件似乎是一个不错的主意。

其中著名的 https://github.com/github/gitignore 就是一个专门收集各类开发语句或IDE 需要忽略的 .gitignore 推荐配置的仓库，目前star 已高达 160K，它也是由 GitHub 官方旗下的一个仓库，目前仍在更新。

官方对它的介绍

This is GitHub’s collection of .gitignore file templates. We use this list to populate the .gitignore template choosers available in the GitHub.com interface when creating new repositories and files.

可以看下收集的各种开发语言或ide 推荐忽略文件

gitig就是一款专用解决这个问题的工具，软件安装后自动包含数据源信息，后期随着数据源仓库的更新也会更新发布新版本，它不需要联网支持直接离线操作，只有不到 2M 大小。

功能介绍

对于它的安装方法也很简单，可以参考 https://github.com/cfanbo/gitig.git 介绍，安装完成后，查看版本号

$ gitig -v
gitig v0.0.3-f306ec4

添加配置项

最常用的操作就是将仓库推荐类型的忽略清单添加到本地的 .gitignore 文件，如上面用 vscode 开发 rust 项目，这时就需要将与 VSCode 相关忽略项与 Rust 语言相关忽略项一并添加到本地 .gitignore文件。

Rust 中错误可分为两大类：可恢复的（recoverable）和 不可恢复的（unrecoverable）错误。

对于一个可恢复的错误，比如文件未找到或权限不足的错误，我们很可能只想向用户报告问题，让用户来决定后续操作。

不可恢复的错误总是 bug 出现的征兆，比如试图访问一个超过数组末端的位置，因此我们要立即停止程序，主要通过 panic! 实现。

panic!

panic!属于不可恢复错误类型，一旦发生程序将立即退出。

fn main() {
    panic!("crash and burn");
}

这里由用户调用 panic! 宏来实现程序的中止，同时自定义错误信息。

➜  cargo run
   Compiling hello-world v0.1.0 (/Users/sxf/workspace/rust/hello-world)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.68s
     Running `target/debug/hello-world`
thread 'main' panicked at src/main.rs:2:5:
crash and burn
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

切记：一旦调用 panic! ，程序将立即中止运行，且无法恢复。

至于什么时候使用 panic! ，可参考文档：要不要 panic!

系统默认错误 unwrap

unwrap 底层调用的 panic!，因此也属于不可恢复错误。

调用 unwrap() 获取 Result 中 Ok(value) 的value，如果 Result 的值为 Err，则直接 panic!() 并中止程序。

在 Rust 中有 包、crate、模块 概念，本文我们介绍一下它们之间的关系和调用方法。

包 和 Crate

在Rust中，包（package）是提供一系列功能的一个或者多个 crate。一个包会包含一个 Cargo.toml 文件，阐述如何去构建这些 crate。

我们先看一下通过 cargo new 创建一个 my_project 包。

➜  cargo new my_project   
    Creating binary (application) `my_project` package
note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

➜  rust tree my_project 
my_project
├── Cargo.toml
└── src
    └── main.rs

2 directories, 2 files

它将创建一个 Cargo.toml文件，内容：

[package]
name = "my_project"
version = "0.1.0"
edition = "2021"

[dependencies]

文件里并没有提到 src/main.rs，因为 Cargo 遵循的一个约定：src/main.rs 就是一个与包同名的二进制 crate 的 crate 根。同样的，Cargo 知道如果包目录中包含 src/lib.rs，则包带有与其同名的库 crate，且 src/lib.rs 是 crate 根。crate 根文件将由 Cargo 传递给 rustc 来实际构建库或者二进制项目。

官方文档将一个模块拆分成多个文件时，介绍的是将原来多个模块写在同一个文件中，拆分成了每个模块一个文件。不过还有一种情况没有提到，如果一个模块中的某个 struct 实现代码过多时，仍写在同一个模块文件的话，维护成本就显的比较高了，这时我们可能还需要对这个 struct 的实现按某种粒度拆分成多个文件来实现。

✗ tree
.
├── main.rs
├── model
│   ├── article.rs // 文章相关
│   └── user.rs // 用户相关
└── model.rs

这里是按官方教程拆分后的样子

• article.rs 是文件模块相关实现 -
• user.rs 是与用户相关的实现
• model.rs 公开模块

model.rs

// src/model.rs

pub mod article;
pub mod user;

pub 关键字表示该模块是公开的，可以被其他模块访问。

mod article 声明了一个名为 article 的模块，并且 Rust 编译器会在同文件名的目录下( src/model/ )找到一个名为 article.rs 或者 src/article/mod.rs 的文件来实现这个模块。

文章模块article.rs

// src/model/article.rs
pub struct Article {
    id: u32,
    title: String,
}

impl Article {
    pub fn new(id: u32, title: String) -> Self {
        Article { id, title }
    }

    pub fn info(&self) {
        println!("Article info [id: {}, title: {}]", self.id, self.title);
    }
}

用户模块 user.rs

今天收到一个项目重构的需求，项目源码使用私有 gitlab 托管平台，但由于考虑安全原因，必须通过vpn软件才可以访问。公司用的vpn客户端是 Pritunl, 看了一下项目主页 https://github.com/pritunl/pritunl-client-electron，发现它是一个 OpenVPN 客户端，是基于Golang+Electron 框架开发的一个跨平台的客户端。

以前主要接触的是 wireGuard 和 openvpn 这两个项目，这个客户端还是第一次听说。不过后面发现使用这个客户端会经常出现DNS无法解析的情况，不清楚具体是什么原因引起的，因此不推荐这个客户端。另外从性能方面考虑openvpn也不是推荐方案，推荐优先考虑 wireGuard 这个项目，它的客户端也是跨平台的，而且性能要比openvpn好太多，代码也少很好，无论维护和开发成本都要低的多。个人有很长一段时间一直用wireGuard作为内网穿透方案，不过此方案需要一个公网IP地址，所以后期换成了更节约成本的解决方案，当然这是另一个话题了，不是本文要介绍的内容。

遇到问题

当在macOS上安装好客户端后，使用同事发给我的vpn配置文件，发现一直无法连接到vpn服务器。第一反映就是怀疑是配置文件有问题，但同事反馈一直这样用的，他也是第一次遇到这个情况，所以就排除了配置文件这个原因。

通过查看客户端也并未发现什么原因，一直在重试连接错误。

初步分析

由于以前做零信任网关时，对于网关客户端的流量拦截也是通过vpn这套机制来实现的，因此知道一般会在客户端机器创建一个 tap/tun 虚拟网卡。同时再创建一些路由规则，根据这些规则将需要代理的流量导入到创建的虚拟网卡。然后客户端再从虚拟网卡读取流量内容，然后通过 UDP 协议传到vpn服务端，最后服务端再解包重放从而进入到 vpn服务所在的内网，最终实现流量代理。

虚拟网卡

因此这里首先就要排查本机是否存在tap/tun虚拟网卡，奇怪的是竟然未发现任何虚拟网卡，为什么无法创建虚拟网卡呢？权限问题？正好本机安装有 Cloudflare WARP 这个软件，打开软件测试后，发现本机是可以正常创建 tun 虚拟网卡的，那这样就排除了权限问题了。

路由规则

上面说过vpn的原理，是通过虚拟网卡和路由来配合使用的，路由规则创建了没有？经排查路由规则也没有创建。

客户端版本

难道是客户端版本的原因？咨询了几个同事，版本有的相同，有的不同，但都可以正常连接服务器，并未出现此现象。

openvpn工作原理

由于一直无法找到原因，因此只能还是从vpn工作原理这块入手了。

前面我们知道了虚拟网卡和路由规则都没有创建，那问题会不会出现在前面的一些初始化步骤呢？要确认这一点，首先我们先看一下 openvpn的实现原理：

1. 建立连接：OpenVPN 客户端与服务器之间首先建立一个 TCP 或 UDP 连接。这个连接可以是客户端主动发起，也可以是服务器响应客户端的请求。
2. 身份验证：在连接建立之后，客户端需要通过提供用户名、密码或其他认证方式（如证书）向服务器进行身份验证，以确保连接的合法性。
3. 密钥交换：通过使用密钥交换协议（如 TLS/SSL），客户端和服务器交换密钥，生成一个共享的对称密钥。这个密钥将用于后续的数据加密和解密过程，确保数据的机密性。
4. 数据传输：一旦加密通道建立，客户端和服务器就可以在其中安全地传输数据。数据在发送前会被使用共享密钥进行加密，接收方在收到数据后会使用相同的密钥进行解密。
5. 使用 TUN/TAP 虚拟网络设备：OpenVPN 利用操作系统内核中的虚拟网络设备 TUN/TAP 来转发数据。TUN 工作在网络层，负责 IP 数据包的传输；TAP 工作在数据链路层，负责以太网帧的传输。这些虚拟设备使得 OpenVPN 能够在用户空间处理网络数据。
6. 配置路由：OpenVPN 服务器会为每个客户端分配一个虚拟 IP 地址，并配置相应的路由规则。这样，客户端就成为了虚拟网络的一部分，可以访问服务器所在网络的其他资源。
7. 数据封装：OpenVPN 将网络层的数据封装在 VPN 数据包中，然后通过物理网络发送。在接收端，OpenVPN 将数据解封装，恢复原始数据包，然后通过虚拟网络设备发送给目标。
8. 安全性：OpenVPN 支持多种加密算法（如 AES、DES、3DES 等），并提供了数据完整性检查和抗重放攻击的特性，增强了通信的安全性。

从VPN实现原理得知，我们上面排查的虚拟网卡和路由规则是步骤中的第5和第6步，现在我们只需要对前面这几步进行确认基本就可以找到原因了。

git merge 与 git rebase 的区别

对于两者的区别，网上已经有很多文章做了介绍，不过有些初学者没有亲自实验过，多数也是作为八股文死记硬背而已。本文为了让大家彻底搞懂两者的区别，所以搞了一个实验环境并模拟了一些真实环境的操作。

实验环境主要用到两个分支，其中 main 分支做了主要分支，而 dev 作为开发功能分支。

在生产环境中需要选择合适的分支，这里只是实验环境，所以分支名不是本文关注的重点。

注意实际提交顺序与合并后git log 记录显示的顺序差异：在 git log 中可以看出在 a.txt - e.txt 之间是连续的，尽管在其提交过程中在main分支也进行了一些提交，git log 的最后才将在main分支中的修改追加在 dev 分支历史记录的后面（4.txt 和 5.txt）。 总结一下，就是当一个分支dev 从另一个基分支 main 拆分出来后。当在基分支通过 git rebase 合并分支时，会将被合并分支所有commit id 顺序提交到git log 后面。如果在其间main分支也做了一些commit, 时会在合并之后再追加到后面。因此如果有冲突的话，合并的时候要确认清楚哪些是最新的代码，这个与使用 git merge 命令是不一样，它是基于时间点顺序合并的。