Mac微信小助手安装指南：版本架构匹配、注入重签名与多开排错-育师

简介：面向需要在 macOS 桌面端提升微信多账号协作与消息处理效率的用户，这份“微信小助手”插件包提供多开登录、快捷回复、消息免打扰、条件自动回复、群聊批量管理、文件下载整理、朋友圈查看及在线状态隐私保护等扩展能力，适合客服、销售及日常多账号办公场景。压缩包共1670个文件，约16.84MB，包含大量png界面与图标资源、nib界面文件、strings本地化文本、plist配置、sh脚本以及insert_dylib等插件相关组件，另有说明文档、Alfred工作流与少量脚本文件，整体兼顾功能资源、界面素材与配置脚本。目前已有641人学习下载，可作为了解macOS微信功能拓展实现思路的参考资料；读者可从中观察插件功能模块划分、菜单界面资源组织、本地化文本与配置脚本的配套方式，并据此评估第三方非官方插件的适用边界、维护成本与潜在安全风险。

1. 版本对齐：Mac 微信小助手装之前先看这三个版本号

装 Mac 微信插件这事，翻车概率最高的一步从来不是「找不到安装包」，而是拿到 zip 之后直接双击、一路下一步，然后微信图标弹一下就没了。我在一台刚升级完系统的机器上复现过这个场景：插件装完，微信启动即闪退，重启、重装微信、重启系统全试过，最后发现是插件库架构和芯片架构对不上。微信 macos 软件/插件这类东西不像普通 App，它要往微信本体里挂一个动态库，只要版本、架构、签名三者有一项不匹配，表现就是闪退或者静默失效，而且不给你任何提示。

这套微信小助手适合三类人：一是日常在 Mac 上高频用微信、希望多开窗口或者做点消息辅助的；二是已经装过一次、被闪退劝退想搞清楚原理的；三是帮别人装、需要一套能回滚流程的。下面按「查版本 → 备份 → 注入 → 配置 → 排错 → 验证」的顺序走一遍，每一步都给命令，照着敲基本不用猜。

2. 装前准备：微信版本、芯片架构与插件包的匹配清单

动手之前先把底数摸清楚，这一步花五分钟，能省掉后面半小时的瞎折腾。插件本质是往/Applications/WeChat.app里塞一个动态库，再改一下 Mach-O 的加载列表，微信每次启动会按自己的签名校验走一遍，所以插件包、微信本体、系统三者必须对得上。

2.1 三条命令查清你机器上的版本底数

先查系统和芯片。系统版本决定签名策略和 Gatekeeper 的严格程度，芯片架构决定插件库能不能被加载——Apple Silicon 机器上跑的是 arm64 进程，塞一个只有 x86_64 的库进去，微信启动瞬间就会崩，而且崩溃报告里写得极其含糊。

# 系统版本，重点看主版本号 sw_vers # 芯片架构：arm64 是 Apple Silicon，x86_64 是 Intel uname -m # 微信本体版本号，两种查法，第二种更准 mdls -name kMDItemVersion /Applications/WeChat.app defaults read /Applications/WeChat.app/Contents/Info.plist CFBundleShortVersionString

sw_vers会输出 ProductVersion，比如 14.x 这类主版本号，插件包里如果自带安装脚本，脚本内部通常会判断这个值决定用哪套签名参数。uname -m是决定成败的一条，很多插件包是分架构打包的，压缩包里常见arm64和x86_64两个目录，选错就是秒崩。最后那条defaults read直接读 Info.plist，比 Spotlight 索引更可靠，因为mdls有时候会因为索引没更新返回空值或者旧值。

查完把三个值记下来，后面每一步都要拿它们对照。我一般的习惯是直接在终端里echo一遍存成文本，出问题时好回溯。

{ echo "macOS: $(sw_vers -productVersion)" echo "Arch : $(uname -m)" echo "WeChat: $(defaults read /Applications/WeChat.app/Contents/Info.plist CFBundleShortVersionString)" } | tee ~/wechat-env-$(date +%Y%m%d).txt

这段用大括号把三条命令的输出拼成一段文本，tee同时打印到屏幕和写进家目录的文件，文件名带日期。出问题的时候把这行文本贴出来，比凭记忆描述「我系统挺新的」有用得多，算是给自己留的后悔药。

2.2 用 ditto 做一份能回滚的微信备份

备份这一步千万别省。微信本体被替换之后，想退回原状只有两条路：重新下载安装包，或者用备份还原。前者要重新登录、重新授权，后者只要几秒钟。

# 建一个固定目录放备份，别放桌面，桌面容易被清理工具扫掉 mkdir -p ~/Backup/WeChat # ditto 会保留资源分支、权限和扩展属性，比 cp -R 稳 sudo ditto /Applications/WeChat.app ~/Backup/WeChat/WeChat_$(date +%Y%m%d_%H%M).app # 顺手记一下大小，还原的时候好核对 du -sh ~/Backup/WeChat/*

为什么用ditto不用cp -R：macOS 的 App 包里带资源分支和扩展属性，cp -R在部分场景下会丢，丢完之后签名直接校验不过，还原回来的 App 反而打不开。ditto是系统自带的、专门干这件事的工具，不需要额外装东西。sudo是因为/Applications下的包归 root 所有，普通用户读得到但复制完整属性需要提权。

聊天数据也要单独看一眼位置，不同版本存放路径不太一样，用通配符找最省事：

# 找微信的数据目录，通常在这两个父目录下 ls -d ~/Library/Containers/*inWeChat* 2>/dev/null ls -d ~/Library/Application\ Support/*inWeChat* 2>/dev/null

找到之后整个目录用ditto复制一份到备份盘。注意这一步要在微信完全退出之后做，运行中复制可能拿到半写状态的数据库文件。

2.3 处理隔离属性与安全策略放行

从压缩包解出来的文件带com.apple.quarantine扩展属性，这是系统给下载文件的标记，带这个标记的可执行文件在被修改后更容易被拦。装插件前先把这个标记清掉，能省掉一大批「应用已损坏」的误报。

# 查看当前有哪些扩展属性 xattr -l /Applications/WeChat.app # 递归清除隔离标记 sudo xattr -dr com.apple.quarantine /Applications/WeChat.app # 插件包解压出来的目录也处理一遍 xattr -dr com.apple.quarantine ~/Downloads/微信插件包目录

-d是删除，-r是递归，后面跟属性名。清完之后再xattr -l看一次，确认输出为空。这一步不改任何签名，只是去掉系统附加的下载来源标记，属于安全操作。

然后是安全策略。插件要正常工作，微信进程有时需要辅助功能权限，装完之后第一次启动会弹窗，去「系统设置 → 隐私与安全性 → 辅助功能」里把微信勾上即可。这里有个血泪经验：勾选之后必须完全退出微信再启动，光关窗口不算退出，菜单栏图标还在就说明进程活着。

# 确认微信进程是否真的退干净了 pgrep -x WeChat # 有输出说明还活着，用正常方式退出，别上来就 kill -9 osascript -e 'quit app "WeChat"'

pgrep -x是按完整进程名精确匹配，比ps aux | grep干净，不会把自己那条 grep 也匹配进去。用osascript发退出事件是让微信走正常的关闭流程，会刷盘、会保存会话；kill -9强杀在消息同步的关键时刻可能让本地数据库处于不一致状态，不到万不得已别用。

2.4 解压后先看目录结构再动手

拿到 zip 之后别急着双击，先列一下内容。

# 不解压，先看包里有什么 unzip -l ~/Downloads/Mac微信小助手.zip # 确认没问题再解压到独立目录 mkdir -p ~/Downloads/wechat-plugin && unzip -o ~/Downloads/Mac微信小助手.zip -d ~/Downloads/wechat-plugin

unzip -l只列清单不解压，能看到有没有安装脚本、有没有分架构目录、README 放在哪。-o是覆盖已存在文件，避免解压到一半停下来问你要不要覆盖。解压出来的目录里如果同时有arm64、x86_64两个子目录，就按 2.1 查到的架构选；如果只有一个目录，用file或lipo看看里面的库是什么架构。

# 看动态库支持的架构 file ~/Downloads/wechat-plugin/**/*.dylib 2>/dev/null lipo -archs ~/Downloads/wechat-plugin/某个库文件.dylib

lipo -archs输出arm64就说明这个库能在 Apple Silicon 上原生加载，输出x86_64 arm64说明是通用二进制，两种机器都能用。如果输出只有x86_64而你的机器是 arm64，别硬上，找对应架构的版本，否则微信必崩。

3. 安装路径：一键脚本和手动注入怎么选

插件包一般提供两种装法：跑脚本，或者手动把库塞进去再重签名。前者快，后者可控。我的建议是第一次装用脚本，出问题时切手动，因为手动过程你能看到每一步到底改了什么，排错时心里有底。

3.1 路径 A：跑插件包里的安装脚本

脚本通常在解压目录根部，名字类似install.sh。跑之前先读一遍，重点看它改哪个路径、用不用sudo、签不签名。

cd ~/Downloads/wechat-plugin ls -la # 先读，别急着执行 less install.sh

读脚本的时候盯三个地方：一是它对/Applications/WeChat.app做的操作是复制还是原地修改；二是结尾有没有codesign那一步，没有的话装完大概率起不来；三是它有没有先判断微信是否在运行。确认没问题再执行：

# 确保微信已退出 pgrep -x WeChat || echo "微信已退出，可以继续" # 加执行权限并运行，脚本内部需要提权的地方会自己调 sudo chmod +x install.sh ./install.sh

pgrep -x WeChat || echo ...这个写法是「找不到进程就打印提示」，||表示前面失败才执行后面。这一步是为了避免微信开着的时候被改包，运行中的进程持有已映射的库文件，改完之后不重启是看不到效果的，而且可能写入失败。

脚本跑完一般会打印几行结果，看到类似「注入成功」「签名完成」的字样才算走完。如果中途报错，把完整输出留下，第 5 章会按报错类型分类处理。

3.2 路径 B：手动把插件库放进 WeChat.app 并重签名

手动流程分四步：拷贝库、改加载列表、重签名、验证。听起来吓人，实际就几条命令，而且每一步都能单独验证。

第一步，把库文件放进 App 的 Frameworks 目录。

# 目录不存在就先建 sudo mkdir -p /Applications/WeChat.app/Contents/Frameworks # 按你的架构选目录，这里以 arm64 为例 sudo cp -R ~/Downloads/wechat-plugin/arm64/插件库.framework \ /Applications/WeChat.app/Contents/Frameworks/ # 确认文件到位、权限正确 ls -la /Applications/WeChat.app/Contents/Frameworks/ | grep -i 插件库

cp -R用于目录形式的 framework，如果是单个.dylib文件就不用-R。放到Contents/Frameworks是 macOS App 的惯例位置，系统加载器会在这个目录下找依赖。权限保持 root:wheel、目录 755 即可，别改成 777，权限过宽反而会被签名校验挑刺。

第二步，让微信主程序加载这个库。插件包里一般带一个插入工具，或者脚本里已经把这一步做完了。手动做的话，核心是往 Mach-O 的加载命令里加一条记录，改完之后用otool验证。

# 看主程序当前加载了哪些库 otool -L /Applications/WeChat.app/Contents/MacOS/WeChat | grep -i 插件库 # 没有任何输出，说明还没挂上

otool -L列出的是 Mach-O 的 LC_LOAD_DYLIB 列表，也就是「启动时要加载哪些库」。这一步的验证意义很大：后面所有排错，第一步都是回来跑这条命令，看注入到底成没成。

第三步，重签名。这是整个流程里最容易漏、也最容易出问题的一步。改过 App 包内任何文件，原有签名就失效了，必须重新签，否则系统直接拒绝启动。

# 先看一下当前签名状态 codesign -dv --verbose=4 /Applications/WeChat.app 2>&1 | head -20 # 强制重签，- 表示 ad-hoc 签名 sudo codesign --force --deep --sign - /Applications/WeChat.app # 验证签名完整性 codesign --verify --deep --strict --verbose=2 /Applications/WeChat.app

--force是覆盖已有签名，--deep是递归签包内所有嵌套的组件（helper、framework、插件都在内），--sign -表示用 ad-hoc 临时签名，不需要开发者证书。新版 macOS 会在输出里提示--deep已废弃，但在这类改包场景下它仍然是最省事的兜底手段；如果--deep之后验证仍然报某个嵌套组件签名无效，就针对那个组件单独再签一次，从内往外逐层签。

第四步，确认签名验证通过。codesign --verify输出valid on disk和satisfies its Designated Requirement两行，才算真正干净。只出现一行或者报code object is not signed at all，说明还有组件没签上。

3.3 首次启动与权限授予清单

签完之后启动微信，第一次启动会比平时慢，因为系统在做一次完整的签名校验。

open -a /Applications/WeChat.app

用open -a而不是双击，好处是启动失败时错误会打到终端或者系统日志里，方便抓。启动起来之后依次确认三件事：

第一，进程有没有活着。pgrep -x WeChat有输出说明进程在。第二，插件库有没有被真正加载进内存。lsof看进程打开的文件列表，比看磁盘上有没有文件靠谱得多。

# 看微信进程实际加载了哪些动态库 lsof -p $(pgrep -x WeChat) | grep -i -E 'dylib|framework' | grep -v '/System/'

-p指定进程号，$(pgrep -x WeChat)直接把进程号取出来传进去。过滤掉/System/下的系统库，剩下的就是 App 自带的库，插件库应该出现在这个列表里。没出现，说明注入没生效，回 3.2 第二步。

第三，权限弹窗。首次启动通常会弹辅助功能授权，去系统设置里勾选，然后完全退出微信（osascript -e 'quit app "WeChat"'）再启动一次。这个顺序不能反，勾完不重启是不生效的。

3.4 装坏了怎么退回去

回滚流程要在装之前就想好，不要等崩了才找。最省事的回滚就是把备份的 App 覆盖回去。

# 完全退出微信 osascript -e 'quit app "WeChat"' pgrep -x WeChat || echo "已退出" # 删掉被改过的包，把备份还原回去 sudo rm -rf /Applications/WeChat.app sudo ditto ~/Backup/WeChat/WeChat_20250101_1200.app /Applications/WeChat.app # 清掉隔离属性，避免还原后打不开 sudo xattr -dr com.apple.quarantine /Applications/WeChat.app open -a /Applications/WeChat.app

rm -rf删的是整个 App 包，所以前面备份必须确认完整。还原之后如果还是闪退，说明问题不在 App 包本身，可能是偏好域里残留了插件的配置键，走 4.1 的方式把偏好导出备份后删掉相关键再试。

4. 配置调整：设置面板里的开关和偏好域里的键

插件装好只是第一步，真正影响体验的是配置。多数这类插件会在微信的设置里插一个自己的面板，也会把开关同步写到偏好域（plist）里。面板好点，但面板偶尔会不显示，这时候只能靠命令行改。

4.1 从偏好域里找到插件真正落盘的键

先要确定微信的偏好域叫什么。不同版本命名会有差异，用defaults domains列出来再筛，比死记硬背强。

# 列出所有偏好域，逗号分隔，转成一行一个再筛 defaults domains | tr ',' '\n' | grep -i -E 'wechat|xin' # 把域名存进变量，后面反复用 DOMAIN=$(defaults domains | tr ',' '\n' | grep -i wechat | head -1 | xargs) echo "$DOMAIN"

tr ',' '\n'把逗号分隔的一长串拆成一行一个，xargs去掉首尾空格，head -1取第一个匹配项。存进DOMAIN变量之后，后面的命令就不用重复写那一长串域名，也不容易抄错。

拿到域名后，先把整份偏好导出备份，再去看里面有哪些和插件相关的键。

# 导出备份，改坏了能导回去 defaults export "$DOMAIN" ~/Backup/wechat-pref-$(date +%Y%m%d).plist # 筛出可能是插件写的键 defaults read "$DOMAIN" | grep -i -E 'tweak|plugin|multi|revoke|enable'

defaults export导出的是完整 plist，用defaults import可以整体还原，比一个个键往回改靠谱。grep那行的关键词是经验值：这类插件写进去的键名通常带 tweak、plugin、multi（多开）、enable 之类的词。具体键名以你机器上实际输出为准，别照抄别人的键名，版本不同名字会变。

找到键之后改值的写法是固定的：

# 布尔开关 defaults write "$DOMAIN" 实际的键名 -bool YES # 改完必须重启微信才生效 osascript -e 'quit app "WeChat"' && sleep 2 && open -a /Applications/WeChat.app

-bool YES表示写入布尔真值，对应的关闭是-bool NO。sleep 2是给进程退出留点时间，退出没完成就启动新实例，可能出现两个进程抢同一份数据的情况。

4.2 多开和消息辅助功能的参数取舍

多开是这类插件里使用频率最高的功能，实现方式通常是允许同一份 App 启动多个实例。命令行本身就能做，不一定依赖插件：

# -n 表示打开一个新实例，即使已有同名应用在运行 open -n -a /Applications/WeChat.app

-n是open的原生参数，作用是强制新开一个实例。用这个方式开出来的第二个窗口和插件提供的多开在行为上略有差别：命令行方式每个实例是独立进程，登录态互不影响；插件方式有时是共享部分数据。实际用下来，命令行多开更干净，缺点是每次都要敲命令，可以写成 alias 放进 shell 配置文件。

# 追加到 ~/.zshrc echo "alias wx2='open -n -a /Applications/WeChat.app'" >> ~/.zshrc source ~/.zshrc

消息辅助类功能（比如消息状态的处理）建议只开你真正需要的项。开得越多，插件要 hook 的入口越多，微信小版本升级后失效的概率越大。我的习惯是装完先只开多开，稳定跑一周再逐项加，出问题能立刻定位是哪个开关引起的。

4.3 微信升级之后插件失效的重装流程

微信自动更新会把整个 App 包替换掉，插件随之消失，这是所有人都会遇到的一次「怎么突然没了」。所以每次微信更新完，按固定流程重走一遍：

# 1. 确认新版本号，和之前记录的在不在同一大版本 defaults read /Applications/WeChat.app/Contents/Info.plist CFBundleShortVersionString # 2. 检查插件是否还在 otool -L /Applications/WeChat.app/Contents/MacOS/WeChat | grep -i 插件库 # 3. 没了就重新走 3.1 或 3.2

第一条命令拿到的版本号如果跨了大版本，插件包可能整体不兼容，别硬装，先看插件包里的说明文件有没有对应版本的目录。第二条命令没输出就说明注入被覆盖掉了，重新装一遍即可。重装之前记得再备份一次新的 App 包，因为这次备份是「干净的新版本」，比旧备份更有价值。

5. 常见问题排查：闪退、面板不出现与注入失败

出问题别急着重装系统。这类插件的故障百分之九十集中在这几类：启动闪退、设置面板不显示、签名校验不过、多开互相干扰、更新后失效。每类都有明确的判断路径。

5.1 先学会看日志和崩溃报告

在动手改任何东西之前，先拿到证据。macOS 有两处信息源：统一日志和崩溃报告。

# 看最近五分钟微信相关的系统日志 log show --predicate 'process == "WeChat"' --last 5m --style compact # 崩溃报告目录，按时间排序看最新的 ls -lt ~/Library/Logs/DiagnosticReports/ | head -10

--predicate是日志的过滤表达式，process == "WeChat"只保留微信进程产生的条目，--last 5m限定时间范围，--style compact让输出紧凑一些。崩溃报告的文件名里带进程名和时间戳，找最新的那个用cat或「控制台」打开，重点看Termination Reason和Library not loaded这两行——前者说明为什么被杀，后者直接告诉你是哪个库加载不了。

5.2 启动即闪退

现象：点开微信，图标在 Dock 上跳一下就消失，没有任何提示，或者弹一个「微信意外退出」。

原因：九成是插件库架构不匹配，或者签名没签全。前面 2.1 查到的uname -m如果是arm64，而插件库只有x86_64，进程加载时直接失败。另一种是--deep签名漏掉了嵌套的 helper。

解决：先验证架构，再验证签名。

# 逐层验证签名，报错会指出具体哪个组件有问题 codesign --verify --deep --strict --verbose=4 /Applications/WeChat.app 2>&1 | grep -i -E 'invalid|not signed' # 确认插件库架构 lipo -archs /Applications/WeChat.app/Contents/Frameworks/插件库.framework/插件库

架构不对就换对应版本的插件包，不要试图用 Rosetta 硬撑，主进程是 arm64 的情况下加载 x86_64 库这条路走不通。签名有问题就针对报错的那个路径单独codesign --force --sign -重签，从最内层往外签，最后再签整个 App。

5.3 提示「应用已损坏」或「无法验证开发者」

现象：微信打不开，弹窗说应用已损坏建议移到废纸篓，或者提示无法验证开发者。

原因：改包之后签名失效，加上从网上下载的隔离属性还在，系统把这两件事叠加判断成了「被篡改的未知来源应用」。

解决：清隔离属性 + 重新 ad-hoc 签名，两步都做，只做一步往往不够。

sudo xattr -dr com.apple.quarantine /Applications/WeChat.app sudo codesign --force --deep --sign - /Applications/WeChat.app codesign --verify --deep --strict --verbose=2 /Applications/WeChat.app xattr -l /Applications/WeChat.app

最后那条xattr -l输出为空才说明属性确实清干净了。如果清完重启又出现，检查是不是有安全软件在重新打标记。

5.4 设置面板找不到

现象：微信能正常启动，多开也能用，但设置里就是没有插件的那个面板。

原因：面板是插件在运行时注入的 UI，注入时机和微信自身的界面初始化有竞争。启动太快、或者偏好域里某个开关被关掉了，面板就不出现。

解决：先确认库到底加载了没有，再确认开关状态。

# 库有没有进内存 lsof -p $(pgrep -x WeChat) | grep -i 插件库 # 偏好域里的开关 DOMAIN=$(defaults domains | tr ',' '\n' | grep -i wechat | head -1 | xargs) defaults read "$DOMAIN" | grep -i -E 'tweak|plugin|enable'

lsof有输出但面板不显示，基本就是开关问题，把相关布尔值改成YES再重启。lsof没输出，说明注入根本没成功，回 3.2 检查otool -L的结果。

5.5 多开窗口之间互相干扰

现象：开了两个实例，其中一个发消息另一个不刷新，或者登录状态互相顶掉。

原因：两个实例共用同一份数据目录，写冲突。微信本身不是为多实例设计的，文件锁的处理不完善。

解决：给第二个实例指定独立的数据目录。部分插件支持通过启动参数切换，命令行方式可以配合环境变量试：

# 先正常开一个 open -a /Applications/WeChat.app # 再开一个独立实例 open -n -a /Applications/WeChat.app --args -dataPath ~/Library/Containers/wechat2

--args后面的内容会原样传给应用，能不能识别取决于微信本体是否支持这个参数，不支持的话不会报错，只是被忽略。实际使用中更稳的做法是两个实例不同时高频操作，或者干脆只用一个主实例加命令行临时多开处理一次性事务。

5.6 覆盖安装后插件全部消失

现象：某天打开微信发现插件没了，多开也用不了。

原因：微信自动更新替换了整个 App 包，注入的库和签名一起被覆盖。

解决：重新走一遍注入流程。这次记得先备份新版本的 App 包，再装插件。另外可以把「检查插件是否还在」做成一条固定命令，每次更新完顺手跑一下：

# 一条命令判断需不需要重装 otool -L /Applications/WeChat.app/Contents/MacOS/WeChat | grep -qi 插件库 \ && echo "插件还在" || echo "需要重新注入"

grep -q是静默模式，只返回状态码不打印内容，配合&&||就能做成一句话的判断。这种小命令看着不起眼，但能省掉每次更新后「盯着设置面板找插件入口」的时间。

6. 装完怎么验证：三个动作确认插件真的挂上了

验证这件事，很多人做到「微信能打开」就停了，结果用了两天才发现某个功能压根没生效。我的做法是固定三个动作，全部通过才算装完。

第一个动作，看磁盘。确认库文件确实在 App 包里，而且架构对得上。

# 库文件在不在 ls -la /Applications/WeChat.app/Contents/Frameworks/ | grep -i 插件库 # 架构对不对 lipo -archs /Applications/WeChat.app/Contents/Frameworks/插件库.framework/插件库

第一条看文件在不在，第二条看arm64或x86_64是否和uname -m的输出一致。两条都过，说明静态层面没问题。

第二个动作，看内存。这一步最关键，也是最多人跳过的一步——磁盘上有文件不代表进程真的加载了。

# 主程序的加载列表里应该有插件库 otool -L /Applications/WeChat.app/Contents/MacOS/WeChat | grep -i 插件库 # 运行中的进程也确认一遍 lsof -p $(pgrep -x WeChat) | grep -i 插件库

otool看的是「写了要加载」，lsof看的是「真的加载了」。两条都有输出才算真的挂上。只otool有输出、lsof没有，通常是签名校验在启动阶段把库拒了，回去看 5.2。

第三个动作，看行为。功能层面挑一个最容易观察的验证，多开最直观：

# 开第二个实例，能起来且两个窗口独立操作，就算通过 open -n -a /Applications/WeChat.app pgrep -x WeChat | wc -l

pgrep输出的行数就是当前微信进程数，开出两个实例应该返回 2。如果返回 1，说明第二个实例启动失败，去看系统日志。

三个动作走完，把关键信息记一行，方便以后对比：

检查项	命令	通过标准
库文件	`ls`Frameworks 目录	文件存在且属主为 root
架构	`lipo -archs`	与`uname -m`一致
加载记录	`otool -L`	输出中出现插件库路径
运行加载	`lsof -p 进程号`	输出中出现插件库路径
功能行为	`open -n`+`pgrep`	进程数为 2，窗口独立可用