关于 Framework 实现并支持 NAPI-External-Module

[MliKiowa]

NapCat Framework New 方案

🔍 现状分析

NapCat 目前的架构存在以下特点：

• 主要工作层：几乎完全工作在 JavaScript 层
• 少量混合：包含少量 Native 代码
• 调用入口：所有调用集中在 EventWrapper 和原始 WrapperSession

💡 重构思路

核心目标

将 NapCat 对于 wrapper.node 的所有调用转换为 eventWrapper 统一处理，实现调用的 RPC 化。

技术方案

借助 NTQQFridaCall 的原理，实现远程 RPC Native Call 到 NTQQ。

🏗️ 新架构设计

graph TD
    A[NapCat-Framework] --> B[IPC通信层]
    B --> C[NTQQ-NapCat-RPC-Call-Tool]
    C --> D[NAPI-Native接口]
    D --> E[NTQQ wrapper.node]
    
    A1[外部 Node.js 环境] -.-> A
    C1[动态模块注入] -.-> C
    E1[NTQQ 核心] -.-> E
    
    style A fill:#e1f5fe
    style C fill:#f3e5f5
    style E fill:#fff3e0

Loading

架构层次说明

层级	组件	运行环境	通信方式
应用层	NapCat-Framework	外部 Node.js	-
通信层	IPC	进程间通信	IPC协议
代理层	NTQQ-NapCat-RPC-Call-Tool	NTQQ进程内注入	动态模块
接口层	NAPI-Native	Native层	NAPI调用
核心层	NTQQ (Wrapper.node)	NTQQ原生模块	-

🚀 实现优势

✅ 架构优势

• 解耦合：NapCat 可运行在外部 Node.js 环境
• 安全性：减少直接访问 NTQQ 内部模块
• 可维护性：统一的 RPC 调用接口
• 扩展性：便于后续功能扩展

🔄 调用流程

NapCat-Framework 
    ↓ (IPC)
NTQQ-NapCat-RPC-Call-Tool 
    ↓ (NAPI-Native)
NTQQ (Wrapper.node)

注意: 此重构方案需要谨慎实施，确保在改进架构的同时不影响现有功能的稳定性。

[MliKiowa]

经过初步原理验证 完成了相关测试 预计作为 5.0.0 或未来的新启动方案