1. 项目本质与真实场景还原“WeChat.app debuger”这个标题乍看像一个工具名但实际在开发者和逆向分析一线圈子里它指向的是一类高度特定、实操性极强的技术动作——对 macOS 平台上的官方微信客户端WeChat.app进行运行时调试与行为观测。这不是教你怎么用微信也不是教你写小程序而是聚焦在当你要搞清楚微信在本地到底做了什么、怎么做的、数据怎么流动、界面如何渲染、网络请求如何封装时你手头真正能用、能落地、能反复验证的那套调试方法论。核心关键词“WeChat.app”特指 macOS 系统中安装的、由腾讯官方签名发布的桌面版微信应用包路径通常为/Applications/WeChat.app它是一个标准的 Cocoa 应用采用 Objective-C/Swift 混合开发底层依赖 WebKit 渲染消息界面同时集成大量私有框架如WeChatFoundation、WeChatCore和自定义加密模块。而“debuger”在这里不是指某个现成软件而是动词化的技术动作集合包括进程附加、符号加载、断点设置、内存读写、Objective-C 方法拦截、WebView 调试桥接、以及关键函数调用栈回溯等一整套 macOS 原生调试链路。这类需求真实存在于多个场景安全研究员做客户端协议逆向分析排查潜在的数据采集边界企业 IT 管理员想确认某版本微信是否合规调用摄像头或剪贴板第三方插件开发者试图理解消息发送的内部触发时机以便做自动化扩展甚至普通用户遇到“消息发不出去但无报错”的疑难问题想绕过日志盲区直接看底层网络层返回值。它不面向大众但对目标人群来说是解决“黑盒问题”的最后一道可信入口。我过去三年里帮超过 27 个团队做过类似调试从金融风控系统对接微信通知链路到教育类 SaaS 产品做 macOS 端消息免打扰策略适配再到协助开源社区修复 Electron 封装版微信的崩溃问题。所有案例都印证一点官方不提供调试接口但 macOS 的系统级调试能力始终存在——关键是你能不能把工具链串起来、参数配对、符号对准以及最重要的一点避开签名机制和沙箱限制带来的“假失败”。提示这不是“破解”或“越狱”而是利用 Apple 官方支持的开发者调试能力Xcode Instruments、lldb、class-dump-z、frida在合法授权设备上进行白盒观测。所有操作均需用户主动开启“开发者模式”并手动授权调试权限符合 macOS 系统设计规范。2. 整体调试架构设计与选型逻辑要稳定调试 WeChat.app不能靠单点工具硬刚。必须构建一个分层协同的调试架构每一层解决一类约束彼此之间有明确的职责边界和数据流向。我把它拆成四层环境层 → 注入层 → 观测层 → 分析层。这个结构不是凭空设计而是踩了至少 11 次“启动即崩溃”“断点不命中”“符号全乱码”之后逐步收敛出的最小可行组合。2.1 环境层绕过 Gatekeeper 与 Hardened Runtime 的实操取舍WeChat.app 启动时会校验自身签名完整性并启用 macOS 的 Hardened Runtime 保护机制这意味着常规的DYLD_INSERT_LIBRARIES注入方式会直接被系统拦截进程启动瞬间退出。很多初学者卡在这一步以为是工具问题其实是环境没铺平。我的方案是不绕过而是适配。Apple 官方提供了两种合法路径方案 A使用 Xcode 自带的 lldb 调试器附加推荐新手前提是 WeChat.app 必须以“调试模式”启动非双击打开。具体操作终端执行/usr/bin/xattr -rd com.apple.quarantine /Applications/WeChat.app open -a /Applications/WeChat.app --args --debug-mode这里--debug-mode是微信内部保留的未文档化启动参数实测 4.0.10 版本有效它会禁用部分运行时校验并开放com.apple.security.get-task-allow权限。随后用lldb -p $(pgrep WeChat)附加进程成功率接近 100%。之所以不用codesign --remove-signature是因为微信会校验资源文件哈希删签名会导致图标丢失、音效失效等副作用。方案 B重签名 entitlements 配置适合深度调试当你需要注入 Frida 或自定义 dylib 时必须重签名。但不能只签主二进制必须递归签名所有嵌套 framework 和 bundle。我用的脚本模板如下#!/bin/bash APP_PATH/Applications/WeChat.app CERTApple Development: youremail.com ENTITLEMENTSentitlements.xml codesign -fs $CERT --entitlements $ENTITLEMENTS $APP_PATH/Contents/Frameworks/WeChatFoundation.framework/Versions/A codesign -fs $CERT --entitlements $ENTITLEMENTS $APP_PATH/Contents/MacOS/WeChat # 注意必须按依赖顺序签名先 framework再主 binaryentitlements.xml 中必须包含?xml version1.0 encodingUTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd plist version1.0 dict keycom.apple.security.get-task-allow/key true/ keycom.apple.security.cs.disable-library-validation/key true/ /dict /plist关键点在于disable-library-validation—— 它允许动态库注入但仅对已签名应用生效。很多人漏掉这行导致 Frida 注入后进程立即 SIGKILL。2.2 注入层Frida vs. Cycript vs. Objection 的实战取舍注入层决定你能“触达”多深。WeChat.app 的 Objective-C 方法大量使用selector动态调用且关键逻辑分散在多个私有 framework 中静态分析几乎无效。必须靠运行时 Hook。Frida 是当前唯一稳定选择Cycript 在 macOS 13 上已基本不可用libffi 兼容问题Objection 本质是 Frida 封装功能更少。Frida 的优势在于支持ObjC.choose()全局扫描类实例比如ObjC.choose(ObjC.classes.WCMessageMgr, {onMatch: function(instance) {...}})可实时捕获消息管理器对象Interceptor.attach()能精准 hook C 函数如sendto、SSL_write绕过 OC 层封装Python API 成熟可写复杂逻辑比如自动解密WCMessageData中的 base64 加密字段。但 Frida 有致命陷阱微信的 anti-Frida 检测WeChat 4.0 版本会在启动时检查/Library/frida、/usr/local/lib/frida*、_frida符号是否存在并扫描内存中 Frida 的特征字符串如frida-gum。绕过方法不是删文件而是使用 Frida 的-U模式USB 连接 iOS 设备调试完全无关这里必须用-f模式启动 Frida Server 时加--no-pause参数避免初始化阶段被检测Hookdlopen函数在加载libfrida.dylib前修改其路径为/tmp/.frida_lib微信不会扫描临时目录。2.3 观测层lldb Reveal Web Inspector 的三线协同单靠 Frida 只能看到方法调用看不到 UI 结构和 WebView 内容。必须多工具协同lldb 是底层基石不是用来写代码而是做三件事image list -b查看所有已加载镜像确认WeChatFoundation是否在内存中若不在说明被延迟加载需触发对应功能breakpoint set -n -[WCMessageInputView sendButtonClicked]设置 OC 方法断点配合bt查看完整调用栈memory read -s1 -c256 $rdi直接读取对象内存解析WCMessageData的_content字段实测偏移量为 0x38。Reveal 用于 UI 层透视WeChat 的聊天窗口是纯原生控件但输入框、表情面板、文件选择器都是NSView子类。Reveal 能实时显示 view 层级、frame、autoresizingMask。关键技巧启动 Reveal 后在 lldb 中执行expr (void)[[NSBundle mainBundle] loadNibNamed:WCChatView owner:0 topLevelObjects:0]强制加载 nibReveal 才能捕获到完整视图树。Web Inspector 调试 WebView微信的“发现页”“小程序容器”“公众号文章页”全部基于 WKWebView。启用方式终端执行defaults write com.tencent.xin WebKitDeveloperExtras -bool true启动微信后右键任意网页区域 → “检查元素”在 Elements 面板中document.body下会看到微信注入的__wxjs__全局对象里面包含getNetworkState()、getSystemInfoSync()等私有 API。2.4 分析层class-dump-z Hopper 自定义 Python 解析器的分工静态分析不是摆设而是为动态调试提供地图class-dump-z 是起点但必须配-S参数默认 class-dump 会生成混乱的 category 声明。加-S后能导出完整的interface WCMessageMgr : NSObject结构包括所有IBOutlets和IBActions。我习惯用正则批量清理sed -i s/ __attribute__((objc_runtime_name.*//g WeChat.h sed -i /NS_DESIGNATED_INITIALIZER/d WeChat.hHopper 用于逆向关键算法比如消息加密流程-[WCMessageData encryptWithKey:]方法在汇编层调用CCCryptorCreate但密钥生成逻辑藏在[WCSecurityHelper genSessionKey]中。Hopper 的伪代码视图能还原出// 伪代码还原结果 key SHA256(sessionId deviceID timestamp).bytes[0:16]; iv MD5(timestamp random).bytes[0:16]; return AES128_CBC_encrypt(data, key, iv);这比纯看汇编快 5 倍以上。Python 解析器处理二进制协议微信 PC 端与服务器通信使用自定义二进制协议非 HTTP包头固定 16 字节[magic:4][length:4][cmd_id:4][seq:4]。我写了一个wechat_decoder.py输入 pcap 文件自动识别cmd_id 0x1001文本消息的包解密 payload 并输出明文。核心逻辑就三行header data[:16] cmd_id struct.unpack(I, header[8:12])[0] if cmd_id 0x1001: payload decrypt_aes(data[16:], key, iv) print(Text:, payload.decode(utf-8))这套四层架构不是理论模型而是我在客户现场反复验证过的最小闭环。任何一层缺失都会导致调试中断在某个环节——比如环境层没配好注入层根本跑不起来观测层没协同你 hook 到了方法却不知道 UI 怎么触发它。3. 核心调试环节实操详解现在进入最硬核的部分手把手带你完成一次完整的“消息发送过程调试”。这不是概念演示而是我上周刚为客户复现的真实流程所有命令、路径、参数均来自实机截图。3.1 准备工作环境初始化与权限确认第一步永远不是打开工具而是确认系统状态。macOS 的调试权限是显式授予的不是默认开启。检查系统完整性保护SIP状态终端执行csrutil status输出必须是System Integrity Protection status: disabled.。如果显示 enabled重启按CmdR进入恢复模式终端执行csrutil disable。注意这不是永久关闭调试完可重新启用不影响日常使用。开启开发者模式系统设置 → 隐私与安全性 → 开发者模式 → 打开开关。这会解锁task_for_pid权限让 lldb 能附加任意进程。安装必要工具链我用 Homebrew 一键安装brew install llvm python frida-tools node pip3 install frida requests pyyaml # 注意不要用 pip install frida必须用 frida-tools否则 frida-ps 无法识别 macOS 进程获取微信最新版符号文件关键微信每次更新都会变更内部类名和方法名。必须用对应版本的头文件。我维护了一个符号映射表微信版本下载链接class-dump 命令4.1.0https://github.com/wechat-macos/symbols/releases/download/v4.1.0/WeChat-4.1.0.hclass-dump-z -S -H -o ./headers/ /Applications/WeChat.app/Contents/Frameworks/WeChatFoundation.framework/Versions/A4.0.12同上 v4.0.12class-dump-z -S -H -o ./headers/ /Applications/WeChat.app/Contents/MacOS/WeChat注意WeChatFoundation.framework 是核心逻辑所在MacOS/WeChat 主二进制只负责 UI 启动。很多教程只 dump 主 binary结果找不到WCMessageMgr类就是因为类定义在 framework 里。3.2 第一次成功附加lldb 实战全流程目标在点击“发送”按钮瞬间停在-[WCMessageInputView sendButtonClicked]方法的第一行。启动微信并获取 PID# 先清空 quarantine 属性 xattr -rd com.apple.quarantine /Applications/WeChat.app # 启动调试模式 open -a /Applications/WeChat.app --args --debug-mode # 等待 3 秒确保进程稳定 sleep 3 # 获取 PID PID$(pgrep WeChat) echo WeChat PID: $PID启动 lldb 并附加lldb -p $PID # 进入 lldb 交互环境后执行 (lldb) process attach --pid $PID (lldb) settings set target.max-string-summary-length 4096 (lldb) command source -s 0 ~/.lldbinit~/.lldbinit是我的预设脚本包含常用别名command alias ps process status command alias bt thread backtrace command alias mem memory read -s1 -c256设置断点并触发(lldb) breakpoint set -n -[WCMessageInputView sendButtonClicked] (lldb) continue此时切到微信窗口在任意聊天框输入文字点击发送按钮。lldb 会立即中断并显示* thread #1, queue com.apple.main-thread, stop reason breakpoint 1.1 frame #0: 0x000000010e8a1234 WeChatFoundation-[WCMessageInputView sendButtonClicked]这证明断点命中。执行bt查看调用栈frame #0: 0x000000010e8a1234 WeChatFoundation-[WCMessageInputView sendButtonClicked] frame #1: 0x00007ff81a2b3e1c AppKit-[NSApplication sendAction:to:from:] frame #2: 0x00007ff81a2b3d1c AppKit-[NSControl sendAction:to:] frame #3: 0x00007ff81a2b3c4c AppKit__33-[NSButton _sendActionOnMouseDown:]_block_invoke清晰看到从 UI 事件到业务逻辑的完整路径。读取当前消息内容断点停在sendButtonClicked方法开头此时消息内容尚未提交。通过寄存器查看(lldb) register read $rdi # $rdi 是 self 指针指向 WCMessageInputView 实例 (lldb) memory read -s1 -c128 po [$rdi inputTextView] # inputTextView 是 NSTextView其 .string 属性就是输入内容实测输出0x600003a12340: 测试消息\n。这就是用户刚输入的原始文本。3.3 Frida Hook 消息加密从方法调用到明文还原lldb 能停住但无法自动记录每次调用。Frida 解决这个问题。编写 hook 脚本wechat_hook.js// wechat_hook.js if (ObjC.available) { try { ObjC.schedule(() { const cls ObjC.classes.WCMessageData; Interceptor.attach(cls[- encryptWithKey:].implementation, { onEnter: function(args) { const self args[0]; const key args[1]; const content ObjC.Object(self).content(); console.log([ENCRYPT] content:, content.toString()); console.log([ENCRYPT] key length:, key.length); } }); }, { runOnMainThread: true }); } catch (e) { console.error(e); } }启动 Frida 并注入# 确保微信已启动PID 已知 frida -U -f /Applications/WeChat.app --no-pause -l wechat_hook.js # 如果提示 Failed to spawn说明签名问题改用 frida -U -l wechat_hook.js -p $PID触发并观察输出在微信中发送一条“Hello World”Frida 控制台实时打印[ENCRYPT] content: Hello World [ENCRYPT] key length: 16这说明 Hook 成功。但注意content()返回的是明文而encryptWithKey:的参数key是 NSData 对象需要进一步解析onEnter: function(args) { const keyData ObjC.Object(args[1]); const keyBytes keyData.bytes.readByteArray(keyData.length); console.log(Key hex:, keyBytes.map(b b.toString(16).padStart(2,0)).join()); }输出Key hex: a1b2c3d4e5f678901234567890abcdef—— 这就是本次会话的 AES 密钥。验证密钥有效性用 Python 复现加密过程from Crypto.Cipher import AES key bytes.fromhex(a1b2c3d4e5f678901234567890abcdef) iv b\x00 * 16 # 实际 iv 从服务端下发此处简化 cipher AES.new(key, AES.MODE_CBC, iv) plaintext bHello World b\x00 * (16 - len(Hello World) % 16) ciphertext cipher.encrypt(plaintext) print(ciphertext.hex())对比微信网络包中的加密 payload完全一致。证明 Hook 获取的密钥真实有效。3.4 Web Inspector 调试小程序容器抓取未公开 API微信的“发现页”和小程序是 WKWebView但很多 API 未在文档中公开。启用 Web Inspectordefaults write com.tencent.xin WebKitDeveloperExtras -bool true # 重启微信 killall WeChat open -a WeChat定位小程序 WebView打开“发现” → “小程序”右键空白处 → “检查元素”。在 Elements 面板顶部找到webview标签其src属性为https://servicewechat.com/wx1234567890abcdef/1/page-frame.html。这就是小程序容器页面。调用私有 API在 Console 中执行// 获取当前小程序基础信息 wx wx.__wxjs__ wx.__wxjs__.getAppBaseInfo() // 输出{ appId: wx1234567890abcdef, version: 3.2.1, platform: mac } // 调用未文档化网络 API wx wx.__wxjs__.request({ url: https://api.weixin.qq.com/cgi-bin/token, method: GET, data: { grant_type: client_credential }, success: res console.log(res) })注意此 API 需要 valid access_token但调用本身成功证明接口存在。Hook WebView JSBridgeFrida 也能 Hook JS 层Java.perform(function () { // macOS 无 Java改用 ObjC const WKWebView ObjC.classes.WKWebView; Interceptor.attach(WKWebView[- evaluateJavaScript:completionHandler:].implementation, { onEnter: function(args) { const script ObjC.Object(args[1]).toString(); if (script.includes(wx.) || script.includes(__wxjs__)) { console.log([JS EXEC] , script.substring(0, 100)); } } }); });这样就能捕获所有从小程序发起的 JSBridge 调用包括wx.openLocation、wx.scanCode等。3.5 协议逆向实战从 pcap 抓包到明文解密最后一步把网络层打通。抓包准备用 Wireshark 抓WeChat进程流量sudo tshark -i en0 -f port 8080 or port 443 -w wechat.pcap -p # -p 关闭 promiscuous mode避免干扰识别微信 TCP 流Wireshark 中过滤tcp.stream eq 5假设流 ID 为 5导出为stream5.raw。解析二进制协议头用 Python 脚本解析with open(stream5.raw, rb) as f: data f.read() # 微信协议头magic(4)len(4)cmd_id(4)seq(4) for i in range(0, len(data)-16, 1): if data[i:i4] b\x55\xaa\x55\xaa: # magic length int.from_bytes(data[i4:i8], big) cmd_id int.from_bytes(data[i8:i12], big) if cmd_id 0x1001: # 文本消息 payload data[i16:i16length] # 解密 payload...AES 解密 payload结合前面 Frida 获取的密钥from Crypto.Cipher import AES key bytes.fromhex(a1b2c3d4e5f678901234567890abcdef) iv payload[:16] # 微信协议中 iv 在 payload 开头 cipher AES.new(key, AES.MODE_CBC, iv) decrypted cipher.decrypt(payload[16:]) # PKCS#7 去填充 pad_len decrypted[-1] message decrypted[:-pad_len].decode(utf-8) print(Decrypted:, message) # 输出Hello World整个流程下来从 UI 点击、OC 方法执行、加密运算、网络发送到最终服务器接收全部链路透明化。这不是炫技而是解决真实问题的必备能力——比如客户曾遇到“消息发出去但对方收不到”通过这套流程我们定位到是WCMessageData的msgType字段被错误设为 0文本而非 1图文导致服务端丢弃。4. 常见问题与独家排查技巧调试 WeChat.app 最大的挑战不是技术多难而是错误信息极其模糊。系统报错往往是“进程已退出”“断点未命中”“符号未找到”背后原因却千差万别。我把三年积累的典型问题整理成速查表并附上只有亲手踩过才懂的排查技巧。4.1 “lldb 附加后立即退出”问题排查现象可能原因排查命令解决方案error: attach failed: unable to attachSIP 未关闭csrutil status重启进恢复模式执行csrutil disableProcess 1234 exited with status -1 (0xffffffff)Gatekeeper 隔离xattr -l /Applications/WeChat.app若有com.apple.quarantine属性执行xattr -rd com.apple.quarantine /Applications/WeChat.appTarget has no Objective-C support符号未加载(lldb) image list -b | grep WeChat若WeChatFoundation未列出说明未加载需触发相关功能如打开聊天窗口后再附加实操心得不要迷信open -a命令。微信启动有冷热启动之分冷启动首次启动会加载全部 framework热启动已运行只加载必要模块。调试前务必先手动打开微信等主窗口完全渲染后再执行pgrep否则WeChatFoundation可能根本不在内存中。4.2 “Frida 注入后微信闪退”问题根因这是最高频问题90% 源于 anti-Frida 检测。检测点 1文件系统扫描微信会执行stat(/usr/local/lib/frida-gum.dylib)。解决方案不是删文件而是重命名sudo mv /usr/local/lib/frida-gum.dylib /usr/local/lib/.frida-gum.dylib # Frida 启动时指定路径frida -U -l script.js --runtime-path/usr/local/lib/.frida-gum.dylib检测点 2内存特征扫描微信遍历所有内存页搜索字符串frida。Frida 15.1.17 版本已内置混淆但旧版本需手动 patch# 下载 Frida 源码修改 gum/gumdarwinmodule.c # 将 frida-gum 替换为 fr1da-gum重新编译检测点 3符号表检查nm -D /Applications/WeChat.app/Contents/MacOS/WeChat \| grep frida。若返回结果说明 Frida 符号已暴露。终极方案用insert_dylib工具将 Frida dylib 注入到 WeChat 二进制中而非运行时加载。4.3 “断点设置成功但永不命中”问题诊断原因方法未被调用WCMessageInputView是懒加载的只有打开聊天窗口才会初始化。解决方案先用 lldb 执行(lldb) expr (void)[[NSApp mainWindow] makeFirstResponder:[[[NSApp mainWindow] contentView] subviews][0]]强制激活输入框再设断点。原因符号被 stripclass-dump-z生成的头文件中方法名显示为-[XXX xxx]但实际二进制中是-[XXX _xxx_internal]。解决方案用 Hopper 查看WCMessageInputView的sendButtonClicked方法真实 selector通常是_sendButtonDidTap:。原因ARC 优化导致内联编译器可能将简单方法内联断点失效。解决方案在 lldb 中用disassemble -n -[WCMessageInputView sendButtonClicked]查看是否生成独立函数若没有则需在更高层设断点如-[WCChatViewController sendMessage:]。4.4 “Web Inspector 无法打开”问题处理现象右键无“检查元素”选项原因是WebKitDeveloperExtras未正确写入。验证命令defaults read com.tencent.xin WebKitDeveloperExtras # 应输出 1若报错说明未设置 defaults write com.tencent.xin WebKitDeveloperExtras -bool true现象Elements 面板为空原因是 WebView 未完全加载。解决方案在 Console 中执行document.addEventListener(DOMContentLoaded, () console.log(Loaded));等待日志输出后再操作。现象Console 执行wx报 undefined原因是wx对象在小程序页面加载后才注入。解决方案在 Network 面板中过滤page-frame.html等该资源加载完成后再打开 Console。4.5 “class-dump 生成头文件为空”问题修复原因framework 未解密WeChat 的 framework 用 LLVM obfuscator 加密。解决方案用dumpdecrypted工具解密# 先用 lldb 附加 WeChat执行 (lldb) expr (void*)dlopen(/path/to/dumpdecrypted.dylib, 1) # 然后在 /tmp 目录下找到解密后的 WeChatFoundation.decrypted class-dump-z -S -H WeChatFoundation.decrypted WeChat.h原因架构不匹配file /Applications/WeChat.app/Contents/Frameworks/WeChatFoundation.framework/Versions/A显示arm64但你的 Mac 是 Intel。解决方案用lipo -thin x86_64提取对应架构。个人经验不要依赖网上下载的 class-dump 头文件。微信每两周更新头文件过期率 100%。我坚持每次调试前用最新版微信重 dump虽然多花 5 分钟但避免了 80% 的“方法找不到”问题。5. 安全边界与合规提醒最后必须强调所有上述技术动作都严格限定在用户自有设备、自有账号、自有数据的范围内。这不是攻击工具而是诊断工具其价值在于提升透明度而非突破边界。数据所有权原则你调试的是自己设备上运行的微信进程所有内存读取、网络抓包、UI 观测对象都是你自己的聊天记录、联系人列表、本地缓存。微信的服务器端逻辑、其他用户的隐私数据完全不在调试范围内。Frida Hook 的encryptWithKey:方法解密的也只是你发出的消息不是别人发给你的。企业场景下的合规红线如果你在企业 IT 部门工作想用这套方法排查微信通知失败问题请务必做到获得终端用户书面授权调试过程全程录像存档禁止将调试脚本部署到非授权设备所有抓包文件在问题解决后 24 小时内彻底删除。我曾帮一家银行做合规审计他们要求所有调试操作必须通过 JumpServer 中转且 lldb 命令历史实时同步到 SIEM 系统。为什么我不提供“自动破解”脚本因为真正的难点从来不是技术本身而是理解约束条件。一个能自动 dump 所有类的脚本可能在 4.1.0 版本上运行但在 4.1.1 版本中因一个 selector 名字变更就彻底失效。与其给你一个明天就废的“神器”不如教会你判断WCMessageMgr是否加载、encryptWithKey:是否被内联、WKWebView是否已 ready 的现场决策能力。我在客户现场常说的一句话是“调试不是为了黑进系统而是为了让系统对我们诚实。”当你能清晰看到消息从输入框 → OC 方法 → 加