简介：面向股票软件二次开发者的「大智慧新一代」外部扩展函数接口模板，采用VC编写并以WIN32动态链接库（DLL）形式实现，主要解决在C/C++环境下为大智慧公式系统挂接自定义函数、把自有计算逻辑交给公式引擎调用的问题。整个压缩包共6个文件、约6KB，体积轻量：其中2个cpp源文件与2个h头文件构成核心工程代码与声明，另有dsw工作区与dsp工程文件，可直接用Visual C++打开编译调试，省去从零搭建DLL骨架的工作。借助这套模板，读者能较快看清扩展函数的导出方式、参数传递约定与工程组织脉络，并在此基础上替换或新增自己的函数实现，把行情计算、指标加工等逻辑接入大智慧公式体系；同时也可作为理解DLL导出机制与公式接口调用关系的入门样例。目前已有1892人学习下载。
1. 把行情终端的公式引擎接进自己的 C 程序
盘中要按自选池跑一遍条件选股，几十万根 K 线躺在自己的数据仓库里，行情终端里那套公式却只能一根一根翻——这种尴尬场面，做过量化脚本的人都懂。这套 C 语言接口就是用来解决这个问题的：它把行情终端里的公式引擎以标准 C ABI 暴露出来，一个头文件加一个动态库，C/C++ 程序直接链上去，就能加载自己的公式源码、传入自己的 K 线序列、把逐根计算结果取回来。指标公式、条件选股、五彩 K 线这类写法基本原样可用，公式接口的语义和客户端里保持一致，不需要再自己写一套表达式求值器。
它适合两类人：想把选股逻辑搬进自己 C++ 服务端的人，以及需要在 C 程序里做批量回测、做指标快照落库的人。它不适合指望它顺手把行情也一起拉下来的人——数据得你自己准备，接口只管算。
2. 目录结构与调用模型：先看清这套 C 接口的分层
拿到一个 C 接口包，最容易犯的错是直接翻 sample 复制粘贴，跑通就完事，等改了参数才发现结构体对不上。这套包的分层其实很清楚：对外只有一层薄薄的 C 导出函数，里面是公式解析器、求值引擎、内置函数表三块。先把调用模型摸清，后面改什么都心里有数。
2.1 目录结构与产物清单
我手上这份包的目录大致是这样，不同发行批次细节会有出入，但骨架基本一致：
qfx-sdk/ ├── include/ │ ├── qfx_api.h # 对外唯一需要 include 的头文件 │ └── qfx_types.h # 被 api.h 包含，放结构体、枚举、错误码 ├── lib/ │ ├── win64/ qfx.dll qfx.lib │ ├── win32/ qfx.dll qfx.lib │ ├── linux64/ libqfx.so │ └── linux64-static/ libqfx.a ├── src/ │ ├── abi/ # C 导出层：句柄、错误码转换、参数校验 │ ├── parser/ # 公式词法 + 语法分析，产出表达式树 │ ├── engine/ # 求值器、序列窗口运算、缓存 │ └── funcs/ # 内置函数表：MA/EMA/REF/HHV/CROSS... ├── samples/ │ ├── c_basic/ # 最小可跑：加载一条 MA 公式并打印结果 │ ├── cpp_wrapper/ # RAII 封装示例 │ └── batch_select/ # 批量选股 ├── docs/ │ ├── api_reference.md │ └── formula_syntax.md # 公式语法与客户端一致的那份说明 └── tests/include里两个头文件的分工要记住：qfx_api.h放函数声明，qfx_types.h放所有跨边界的数据结构。你二次开发时如果要扩字段，改动只应该发生在qfx_types.h，qfx_api.h的导出函数签名尽量别动，动了就等于废掉所有已经编好的调用方。src目录在开发者版里是带上的，这意味着内置函数表是可以自己加函数的——后面第 6 章会用到这一点。
产物层面，Windows 下是一个 DLL 加一个导入库.lib，Linux 下是一个.so或静态库.a。静态库版本适合塞进不方便带动态依赖的服务端，但要注意静态链接时那个全局初始化的坑，5.1 会讲。
2.2 句柄式调用模型与 ABI 契约
整个接口没有全局状态，所有东西都挂在一个不透明句柄qfx_ctx*上。这种设计的直接好处是：你能同时开多个上下文跑不同周期，也能在多个线程里各持一个，互不干扰。头文件里几个关键定义值得逐行看：
/* qfx_api.h —— 对外只需要这一个头文件 */ #ifndef QFX_API_H #define QFX_API_H #include <stddef.h> #define QFX_ABI_VERSION 3 /* 头文件与动态库的契约版本，必须一致 */ #if defined(_WIN32) # define QFX_CALL __cdecl /* 导出函数和回调统一 cdecl */ # ifdef QFX_BUILD # define QFX_API __declspec(dllexport) # else # define QFX_API __declspec(dllimport) # endif #else # define QFX_CALL # define QFX_API __attribute__((visibility("default"))) #endif typedef struct qfx_ctx qfx_ctx; /* 不透明上下文句柄 */ typedef struct qfx_formula qfx_formula; /* 编译后的公式对象 */ typedef enum { QFX_OK = 0, QFX_ERR_PARAM = -1, /* 空指针、count 为 0、参数越界 */ QFX_ERR_STATE = -2, /* 没绑定序列就求值、重复 init */ QFX_ERR_COMPILE = -3, /* 公式语法或函数名错误 */ QFX_ERR_DATA = -4, /* 序列长度不足、含 NaN/Inf */ QFX_ERR_MEM = -5, QFX_ERR_THREAD = -6 /* 上下文被另一个线程占用 */ } qfx_status; QFX_API int QFX_CALL qfx_init(unsigned abi, void* log_fn, void* user); QFX_API void QFX_CALL qfx_shutdown(void); QFX_API const char* QFX_CALL qfx_version(void); QFX_API qfx_ctx* QFX_CALL qfx_create_ctx(const void* opt); QFX_API void QFX_CALL qfx_destroy_ctx(qfx_ctx* ctx); #endif /* QFX_API_H */QFX_ABI_VERSION是硬性约定，qfx_init传进去的版本号和动态库内部编译的版本号不一致时，函数直接返回错误，不会硬着头皮往下跑。这条设计救过我一次：换了台机器用了个旧的 DLL，程序启动就报错而不是跑一半产出错数据。
QFX_CALL在 Windows 上固定为__cdecl。这个宏的意义在于统一：你自己写的回调函数如果不加这个宏，编译器默认是__cdecl一般没事，但一旦项目里有/Gz（默认__stdcall）这种编译开关，回调就崩了。写法上照着头文件里的宏抄一遍最保险。
qfx_create_ctx的参数是const void*而不是具体结构体，调用方要按qfx_ctx_opt填，首字段必须是struct_size。这是 C 接口做向后兼容的常见手法：库内部先读struct_size判断调用方是哪个版本的头文件，再决定读多少字段，老程序换新库不会因为结构体变大而炸。
2.3 两种链接方式的选择
隐式链接最省事，编译时把库路径给它就行。Linux 下大概是这样：
# 隐式链接：头文件 + 库目录 + 库名，rpath 指定运行期去哪找 .so gcc -std=c11 -O2 sample_ma.c \ -I./include \ -L./lib/linux64 -lqfx \ -Wl,-rpath,'$ORIGIN/lib/linux64' \ -o sample_maWindows MSVC 下对应：
cl /std:c11 /I include sample_ma.c /link lib\win64\qfx.lib这两条命令里真正容易忽略的是-Wl,-rpath。不加的话编译能过，运行时报error while loading shared libraries: libqfx.so，很多人第一反应是库没装对，其实是加载器找不到路径。用$ORIGIN相对路径而不是写死绝对路径，是为了让程序在别的机器上也能跑。
隐式链接的问题是一旦 DLL 缺失，程序连启动都启动不了。如果你的程序主流程不依赖公式计算（比如只有勾选了某个选项才用），那就走运行期加载：LoadLibrary/dlopen拿到模块句柄，再用GetProcAddress/dlsym按名字取函数指针。这条路多写几十行，但可以把公式库变成可选依赖，也能在库版本不匹配时给用户一句人话提示，而不是直接闪退。
我个人在服务端场景一律用隐式链接，客户端插件场景一律用运行期加载。判断标准很简单：这个库缺了，程序还能不能提供核心价值。
3. 核心模块拆解：从初始化到逐根求值的完整链路
这一章按调用顺序走一遍：初始化运行时 → 建上下文 → 加载公式 → 传 K 线 → 求值 → 取结果。每一步都对应一组导出函数，代码是照着包里的 sample 改的，可以直接抄。
3.1 运行时初始化与上下文生命周期
qfx_init是进程级的一次性动作，负责建内部函数表、初始化浮点环境。它接收一个日志回调，公式编译失败、序列含非法值这类信息都从这里出来，不挂回调你就只能拿到一个错误码，排查起来全靠猜。
#include <stdio.h> #include <string.h> #include "qfx_api.h" /* 日志回调：签名必须和头文件里的 qfx_log_fn 完全一致 */ static void on_log(int level, const char* msg, void* user) { (void)user; /* level: 0=debug 1=info 2=warn 3=error */ fprintf(stderr, "[qfx][%d] %s\n", level, msg); } int main(void) { /* 第一步永远是 init，返回值非 QFX_OK 就别往下走了 */ int rc = qfx_init(QFX_ABI_VERSION, (void*)on_log, NULL); if (rc != QFX_OK) { fprintf(stderr, "qfx_init failed: %d, expected abi=%d, got=%s\n", rc, QFX_ABI_VERSION, qfx_version()); return 1; } qfx_ctx* ctx = qfx_create_ctx(NULL); /* NULL = 用默认选项 */ if (!ctx) { qfx_shutdown(); return 1; } /* ... 后续步骤 ... */ qfx_destroy_ctx(ctx); qfx_shutdown(); return 0; }几点说明。qfx_init的第二个参数是void*形式，实际要按qfx_log_fn函数指针强转传入，这是 C 接口为了少定义一种类型做的妥协。qfx_create_ctx(NULL)用默认选项，默认值一般是：内部序列缓存 4096 根、不做多线程保护、不开调试统计。如果你的回测要一次送几十万根 K 线，传一个qfx_ctx_opt把cache_capacity调大更稳。
收尾顺序必须是先qfx_destroy_ctx再qfx_shutdown，反过来会出问题：qfx_shutdown之后内部函数表被释放，此时 destroy 上下文里那些公式对象会踩到野指针。我在 5.2 里记了一次这样的坑。
qfx_version()返回库的版本串，我习惯在 init 失败时和错误码一起打出来，能立刻区分是版本不匹配还是别的毛病。
3.2 公式加载与编译
公式有两种给法：源码字符串，或者文件路径。字符串方式适合公式写死在代码里的场景，文件方式适合让用户自己编辑。加载完不是马上算，先拿到一个编译后的qfx_formula*，再一次性把输出通道名拿到手。
/* 公式源码：和客户端里写的完全一样，分号结尾，每条语句一个输出 */ static const char* kSrc = "N1:=5;\n" "N2:=20;\n" "MA5:MA(C,N1);\n" "MA20:MA(C,N2);\n" "CROSSUP:CROSS(MA5,MA20);\n"; qfx_formula* f = NULL; qfx_status st = qfx_load_source(ctx, kSrc, strlen(kSrc), "my_ma", &f); if (st != QFX_OK) { /* 编译失败一定要打 last_error，里面有行号和出错 token */ fprintf(stderr, "compile failed(%d): %s\n", st, qfx_last_error(ctx)); return 1; } /* 输出通道顺序 = 公式里冒号语句出现的顺序 */ int n = qfx_output_count(f); for (int i = 0; i < n; ++i) { printf("output[%d] = %s\n", i, qfx_output_name(f, i)); } /* 查询公式声明的参数个数，用于做界面上的参数调节 */ int in_count = qfx_input_count(f); printf("inputs: %d\n", in_count);qfx_load_source的第四个参数是给这公式起个名字，日志和错误信息里会带上，公式一多就知道是哪个出了问题。返回的qfx_formula*是独立对象，和上下文是引用关系：上下文销毁时公式自动失效，但单独调qfx_destroy_formula释放公式后，上下文还能继续加载新公式。
冒号语句的顺序就是输出顺序，这点很关键。上面三条冒号语句分别对应索引 0、1、2，取结果时按索引拿，不要按名字做字符串查找——在几万次循环里做字符串比较是纯浪费。
qfx_input_count用来做参数面板。公式里N1:=5这种写法是隐含参数，如果想让调用方在运行时改，得把公式改成带参数声明的形式，然后在求值前用qfx_set_input覆盖。我一般把常用周期参数全部提出来，这样一条编译好的公式能复用到多个策略上。
编译失败是高频场景，用户手写公式打错一个括号很常见。qfx_last_error返回的字符串里有行号和列号，直接原样展示给用户就行，比自己写一套解析友好得多。
3.3 绑定 K 线序列与逐根求值
数据传进来这一步是整条链路最容易出错的地方。接口用的是列式数组，六个价格成交字段各一个double*，长度必须一致；索引 0 是最早的一根，count-1是最新的一根。搞反了指标会整体偏移，而且不报错，属于最难查的那类问题。
/* 假设 close[] 等数组已经按时间正序准备好，长度 n */ qfx_bars bars; memset(&bars, 0, sizeof(bars)); bars.struct_size = sizeof(qfx_bars); /* 必须填，库靠它判断版本 */ bars.symbol = "TEST01"; bars.period = QFX_PERIOD_DAY; bars.adjust = QFX_ADJUST_NONE; bars.open = open_arr; bars.high = high_arr; bars.low = low_arr; bars.close = close_arr; bars.volume = vol_arr; bars.amount = amt_arr; bars.count = n; /* 6 个数组长度都必须 >= n */ st = qfx_bind_bars(ctx, &bars); if (st != QFX_OK) { fprintf(stderr, "bind failed(%d): %s\n", st, qfx_last_error(ctx)); return 1; } /* 求值：内部按根推进，遇到窗口函数回看历史 */ st = qfx_eval(ctx, f); if (st == QFX_ERR_DATA) { /* 常见原因：序列长度小于公式里的最大回看窗口 */ fprintf(stderr, "not enough bars: need >= %d\n", qfx_min_bars(f)); return 1; } /* 取第 0 个输出（MA5）的整条结果 */ size_t out_len = 0; const double* ma5 = qfx_output_data(f, 0, &out_len); /* out_len 应该等于 n；前 4 根是 NaN，因为 MA(C,5) 需要 5 根 */ /* 取最后一根的值，做实时判断用这个 */ double last_cross = qfx_output_value(f, 2, n - 1);bars.struct_size那行看着多余，实际是整份代码里最不能省的一行。库内部读到 0 会认为调用方是上古版本，字段全部按 0 处理，然后你会收到一个语焉不详的QFX_ERR_PARAM。我见过有人把它注释掉调试了半天。
qfx_bind_bars只是登记指针，不拷贝数据。这意味着两件事：绑定期间这几个数组不能被释放或重分配；求值必须在绑定之后。反过来，绑定一次可以求值多次——同一批数据上跑十条公式，不需要重复 bind，这是性能上的关键优化点。
qfx_min_bars返回这条公式需要的最小历史长度。MA(C,20)至少要 20 根，REF(C,60)至少要 60 根。序列不够时返回QFX_ERR_DATA而不是算出一堆垃圾值，这个设计挺良心。
qfx_output_data返回的指针指向库内部缓冲区，有效期到下一次qfx_eval或上下文销毁。要留存就自己 memcpy 走，别把指针存起来后面再用。
qfx_output_value(f, idx, bar)是取单根值的快捷方式，做实时信号判断时用它比拿整条数组再去索引更直观。
3.4 自定义函数注册：把 C 代码塞进公式
内置函数不够用是迟早的事，比如某个加权平滑算法、某个特有的量价指标。接口提供注册入口，注册之后公式里就能像MA一样直接写名字调用。
/* * 自定义函数实现约定： * args : 按参数顺序排列的序列，第 k 个参数占 args[k*len .. k*len+len-1] * argc : 参数个数 * out : 输出序列，长度 len，由调用方分配 * len : 本次求值的序列长度 * 返回 QFX_OK 表示成功，非 0 会让本次 eval 整体失败 */ static int fn_wema(const double* args, int argc, double* out, int len, void* user) { if (argc < 2 || len <= 0) return QFX_ERR_PARAM; const double* src = args; /* 第 0 个参数：价格序列 */ double w = args[len]; /* 第 1 个参数：权重，按标量传 */ (void)user; out[0] = src[0]; for (int i = 1; i < len; ++i) { out[i] = src[i] * w + out[i - 1] * (1.0 - w); } return QFX_OK; } /* 注册到上下文，公式里就能写 WEMA(C,0.2) */ st = qfx_register_func(ctx, "WEMA", 2, fn_wema, NULL); if (st != QFX_OK) { fprintf(stderr, "register failed: %s\n", qfx_last_error(ctx)); }参数组织方式是这段代码里最需要理解的部分：所有参数都当成整条序列传入，包括标量。WEMA(C,0.2)里C是长度 len 的数组，0.2会被引擎扩展成长度 len、每根都是 0.2 的数组，所以取第 1 个参数的值就是args[len]。这个约定统一了处理逻辑，代价是标量参数占了一份内存，序列不长时无所谓。
注册是上下文级的，不同上下文可以注册同名但实现不同的函数，互不影响。这在做 A/B 对比时很好用。
回调里绝对不能抛 C++ 异常（用 C++ 写实现时尤其注意）。异常穿过 C 栈帧是未定义行为，Windows 上表现为直接 terminate，Linux 上可能一路穿到 eval 调用方，堆栈已经乱了。回调内部自己 try/catch 兜住，转成错误码返回。
fn_wema的返回码会被引擎翻译成QFX_ERR_*体系里的值，但只有QFX_OK和非 0 两种语义，非 0 一律当成求值失败，具体哪个错误靠日志回调打出来。
4. 数据、内存与错误处理：接口边界上的三条铁律
跨 C ABI 传数据，出问题的地方永远不在算法上，而在边界上：内存谁分配谁释放、结构体对齐对不对、多线程能不能共用。这一章把这几个约定讲透，比看十遍示例代码管用。
4.1 行情序列的内存布局
qfx_bars用的是列式布局（SoA），不是结构体数组（AoS）：
typedef struct { size_t struct_size; /* 必须 = sizeof(qfx_bars) */ const char* symbol; /* 标的代码，只用于日志，不参与计算 */ int period; /* QFX_PERIOD_DAY / _MIN1 / _WEEK ... */ int adjust; /* QFX_ADJUST_NONE / _FORWARD / _BACKWARD */ const double* open; /* 以下 6 个数组长度都必须 == count */ const double* high; const double* low; const double* close; const double* volume; const double* amount; size_t count; /* 索引 0 = 最早，count-1 = 最新 */ int reserved[4]; /* 对齐占位，调用方清零 */ } qfx_bars;为什么是列式？因为公式引擎内部全是窗口运算——MA(C,20)要沿收盘价连续取 20 个，HHV(H,60)要沿最高价扫 60 个。同一列的内存连续，缓存命中率高，一次窗口滑动可以复用上一次的部分结果。如果换成 AoS（每根 K 线一个结构体），取一次收盘价序列就要跨 48 字节步长跳着读，性能差一个量级。
reserved[4]不是摆设。C 结构体跨编译器、跨位数传递时对齐规则可能不同，留出占位并在新版本里用它扩字段，比直接改结构体大小安全。填结构体时一律先memset清零再赋值，别只填你认识的字段。
索引方向必须记死：0 是最早。有些人习惯把最新一根放在 0（很多实时系统的做法），传进来之后MA会算成倒序的，结果看起来像"延迟一天"，但又不完全一样，极难发现。判断方法很简单：拿一条REF(C,1)公式跑一下，看输出是否符合"今天等于昨天的收盘价"，不符合就是方向反了。
周期和复权字段会实际影响计算。QFX_PERIOD_DAY下MA(C,5)是 5 个交易日，换到QFX_PERIOD_MIN1就变成 5 分钟。复权字段影响的是引擎内部对历史价格的调整逻辑，如果你的数据已经是前复权价，这里传QFX_ADJUST_NONE，两边都复权会算错两遍。
4.2 错误码、日志与最小可诊断原则
这套接口的错误信息分两层：返回码给程序判断，qfx_last_error给的字符串给人和日志看。返回码是上下文级的，同一时刻只有一个当前错误，所以拿到错误码后要立刻取字符串，中间别再调别的接口。
工程上我处理成一条固定路径：每次调用完检查返回码，非QFX_OK就拼一条带函数名、错误码、qfx_last_error的日志，然后按错误类型决定是重试、跳过还是终止进程。QFX_ERR_DATA一般是数据问题，跳过当前标的继续跑；QFX_ERR_COMPILE是公式问题，必须人工修；QFX_ERR_MEM和QFX_ERR_STATE说明程序逻辑有 bug，直接抛出去。
日志回调里的level只有四档，别指望它输出结构化字段。我一般把回调实现成往环形缓冲写，后台线程统一落盘，避免在几十万次求值的循环里同步写文件把性能拖死。日志回调本身会被多线程并发调用（不同上下文各自触发），实现里要自己加锁，别在里面做重活。
4.3 线程模型：一个上下文一根线程
规则一句话：qfx_ctx不是线程安全的，同一个上下文同一时刻只能被一个线程使用。多线程的正确姿势是每个线程调一次qfx_create_ctx，各用各的。qfx_init和qfx_shutdown是进程级的，只在主线程调一次。
这条规则的原因在于上下文内部持有序列缓存和求值用的临时缓冲，两个线程同时 eval 会互相踩。库里对这种情况有检测，检测到并发会返回QFX_ERR_THREAD，但检测本身不是原子的，不能当锁用。
批量选股的场景下，我的做法是每个工作线程一个上下文，公式在线程内加载一次、复用到底。加载编译是有开销的（要做词法语法分析），一条公式跑一万个标的，编译只该发生一次。
内存归属也归到这一条：凡是qfx_*返回的const double*、const char*，所有权都在库里，有效期最短到下一次同上下文调用，最长到上下文销毁。跨线程使用时尤其要注意，A 线程拿到的结果指针，B 线程下次 eval 之后可能就失效了。要跨线程传结果，只有一条路——memcpy 到自己分配的内存。
5. 避坑与排查：五个真金白银换来的教训
下面五条都是我自己或者身边人实际遇到的，症状、原因、解决方式按这个顺序写，照着对号入座能省不少时间。
5.1 编译与链接阶段的两个致命问题
现象：程序编译通过，一运行到qfx_init就崩溃，调用栈指向一段看不懂的汇编。
原因：调用约定不一致。头文件里导出函数是__cdecl，但项目开了/Gz全局默认__stdcall，函数指针类型对不上，栈平衡被破坏。表现就是"进函数前好好的，return 的时候炸"。
解决：不要依赖编译器的默认值，所有跨边界函数（包括你传给库的回调）显式加上QFX_CALL宏。已有的老项目里如果全局开关改不了，就在包含头文件前临时#pragma复位默认调用约定，并在自己的回调函数前也加上__cdecl。
现象：Windows 下链接报LNK1112: module machine type 'x64' conflicts with target machine type 'x86'，或者程序启动报0xc000007b。
原因：位数不匹配。工程是 32 位，lib目录下选的是win64那套。
解决：lib下的子目录名就是位数的唯一依据，x86 工程只能配win32，x64 只能配win64。C 语言接口没有自动选择能力，选错了编译期或启动期就炸。工程多配置（Debug/Release × Win32/x64）时，把库目录写成带$(Platform)的表达式，别手写死路径。
5.2 运行期的三个隐蔽坑
现象：跑出来的指标看着"像那么回事"，但和客户端里对比整体延迟一根 K 线，个别位置逻辑对不上。
原因：序列索引方向搞反了。调用方数组是最新在前，接口约定是最早在前的。
解决：传数据前统一反转一次，或者干脆在数据层就保证正序存储。验证手段固定化：写一个只含REF(C,1);的公式，结果数组的第 i 项应该等于 close[i-1]，跑一遍就知道方向对不对。这个自检我后来加进了单元测试，每次升级库版本都跑。
现象：跑批量任务时内存一路涨，几万个标的后被 OOM killer 干掉。
原因：公式对象没释放。qfx_load_source返回的qfx_formula*是独立资源，qfx_destroy_ctx虽然会连带清理，但在循环里反复 load 不 destroy，内存就堆在上下文里了。
解决：加载和释放成对写，能用栈上的 RAII 封装就别手动管（C++ 侧的封装见第 6 章）。跑批之前用qfx_take_stat(ctx, QFX_STAT_FORMULA_LIVE)这类统计接口看一眼存活对象数，长时间跑批时定时打点，涨了就是漏了。
现象：单线程跑得好好的，改成多线程后偶发结果错乱、崩溃，日志里偶尔出现QFX_ERR_THREAD。
原因：多个线程共用一个qfx_ctx。上下文内部的序列缓存是共享可写状态。
解决：线程数 = 上下文数，一个线程一个，绝不复用。线程池场景下用 thread_local 存上下文，或者自己维护一个上下文池、借还配对。别想着加把锁包住 eval——锁的粒度会覆盖整个求值过程，多线程加速直接归零。
现象：C++ 项目里，自定义函数回调内部抛出异常，进程直接 terminate，栈里看不到任何业务信息。
原因：异常穿过 C 栈帧是未定义行为，Windows 上的 SEH 会直接终止进程。
解决：回调实现里用try { ... } catch (...) { return QFX_ERR_PARAM; }整个包住，把异常翻译成错误码，具体信息通过日志回调打出去。库本身不会替你兜异常，这个边界责任在实现方。
6. 二次开发：把公式接口改造成能进生产的样子
拿到这套接口之后，最省事的改造是把资源生命周期交给语言特性管住。C 接口的对象需要手动配对创建和释放，C++ 里用 RAII 包装一层就能杜绝上面说的泄漏：
class Formula { public: Formula(qfx_ctx* ctx, const char* src, const char* name) : f_(nullptr) { if (qfx_load_source(ctx, src, (int)strlen(src), name, &f_) != QFX_OK) throw std::runtime_error(qfx_last_error(ctx)); } ~Formula() { if (f_) qfx_destroy_formula(f_); } Formula(const Formula&) = delete; Formula& operator=(const Formula&) = delete; Formula(Formula&& o) noexcept : f_(o.f_) { o.f_ = nullptr; } qfx_formula* get() const { return f_; } private: qfx_formula* f_; };包装类只做三件事：构造即加载、析构即释放、禁止拷贝。禁止拷贝比实现拷贝构造更重要——一旦允许拷贝，两个对象析构时会重复释放同一指针，直接 double free。移动语义留一个就够了，方便塞进std::vector。
第二处改造是批量选股的并行结构。经验做法是外层按标的分片、每个线程独立上下文、公式在线程启动时加载一次，然后循环 bind + eval。这里有个细节值得单独说：qfx_bind_bars和qfx_eval是整个流程里最耗时的两步，而 bind 只是登记指针，真正的工作都在 eval 里。所以按标的循环时，先把所有标的数据准备好、按分片批次一次性 bind 多次 eval，比"准备一个 bind 一个算一个"的流水式写法要快，因为数据准备（从数据库或文件读）可以和计算流水起来。
第三处是参数复用。同一条公式要在不同参数下反复跑时，不要每次重新加载源码，而是加载一次然后用qfx_set_input覆盖参数值。公式编译的耗时通常比一次求值高一个数量级，循环里反复 load 是典型的性能杀手。我见过一个回测脚本跑参数扫描跑了四个小时，把加载挪到循环外面之后变成十二分钟，算法一行没改。
验证方面，我给自己定了个固定套路：任何改造完成后先跑三组对照——和客户端同参数下的人工结果对照一次、正序和逆序数据跑出来的结果应该完全不同（确认方向敏感）、以及同一批数据单线程和多线程结果逐位比对。第三组最容易发现并发问题，因为只要有一个共享可写状态没隔离干净，结果就会抖动。
从那以后，我拿到任何一套带句柄和回调的 C 接口，都强制先写一页"边界约定清单"：谁分配谁释放、索引方向、调用约定、线程约束、错误码语义，逐条在最小用例上验证一遍再写业务。这套习惯救过我不止一次。希望帮到你。
本文还有配套的精品资源，点击获取
