简介：这是一份面向通达信二次开发者的C语言插件示例工程，核心演示如何在通达信软件中通过DLL公式接口注册并调用移动平均线（MA）算法。资源以C/C++源码为主，包含3个cpp、3个h源文件与dsp、dsw、plg等Visual Studio工程配置，以及ReadMe说明文档，共12个文件，压缩包仅10KB，结构精简，便于快速阅读和复刻工程环境。已有780人浏览学习，可作为量化交易或指标定制入门参考。通过阅读源码和配置文件，可以掌握通达信DLL公式的接口约定、C插件与主程序的通信方式、MA指标的计算流程，并进一步理解如何封装行情数据、扩展自定义函数。对熟悉C语言、希望进入通达信金融接口开发的读者来说，这份资源提供了可运行的示例骨架和清晰的工程组织方式，能有效降低自行摸索API与工程配置的成本，便于在此基础上编写更复杂的指标或交易策略。
1. 先用一个场景把问题说清楚
当你在通达信公式编辑器里顺手写下MA(C, 20)时，很容易默认所有指标都能靠内置函数拼出来。直到你想实现一个带循环、递归，或者需要对历史区间做自定义统计的算法，公式语言开始变得别扭：没有数组下标访问历史数据有限、没有局部变量做复杂状态、循环结构写起来费劲。通达信DLL公式接口（像 TestPluginTCale.zip 这类样例包）就是留给 C 语言开发者的插件通道：用 C/C++ 写一个 DLL，把移动平均这类计算挪进去，再在公式里一行调用，得到和内置函数等价的结果。它的核心价值不是替代MA，而是让「公式表达不了」的逻辑能在通达信里跑起来，同时保留绘图、选股、预警这些原生体验。适合已经会写基础公式、又愿意碰 C 语言的开发者，是从公式脚本跨向量化实现的最短路径。
2. 通达信DLL公式的C接口协议：先看懂插件的数据交换方式
写 DLL 公式之前，脑子里要先有一个模型：通达信不是把你的 DLL 常驻内存反复调函数，而是在每一次完整指标计算时，通过导出函数把整段K线数据传给你，你算完结果写回内存，一次调用处理一批数据。这个「一批」的设计决定了很多事——你不能像写普通程序那样在函数里设断点慢慢看，也不能指望把状态保存在全局变量里跨调用使用。
2.1 插件数据交换结构：一次计算传入什么、传出什么
通行的通达信 DLL 公式插件，核心数据结构是类似的，大多包含四个字段：数据根数、参数个数、参数数组指针、数据数组指针。样例里常见的是PluginCalcData这个命名。我给你它的典型形态：
typedef struct { int nNumData; // 输入数据的根数，也就是K线数量 int nParam; // 参数个数，对应公式里传给DLL的参数数量 float* pParam; // 参数数组首地址，比如周期数 N 就在 pParam[0] float* pData; // 输入数据序列，如收盘价，按时间从旧到新排列 } PluginCalcData;一次调用流程是老少皆宜的批处理：通达信把当前界面上可见的K线段（甚至全市场选股时的每只股票全量数据）铺在pData里，nNumData告诉你有多少根；你在导出函数里对pData逐根计算，把结果写进pOut指向的输出缓冲区，然后返回一个非零值表示成功。注意，程序集面向的输入输出都是float单精度。
这里最容易理解错的是pParam。它不是让你从 DLL 里读配置文件，而是通达信在公式里调用你时，把你在公式参数位置写的字面量（比如5、10）按顺序塞进pParam数组。所以你的 DLL 必须自己去判断nParam够不够，再决定要不要取pParam[0]。后面避坑章节我会专门讲这个字段的一个坑，这里先记住它的角色。
2.2 MA算法在C接口下的数学定义与滑窗计算
MA（Moving Average，简单移动平均线）的数学定义不用多讲：第i根K线的 MA(N) 值，是i往前N根（含当前）收盘价的算术平均。公式语言里写MA(C, 5)，等价于 C 语言里对序列做长度为 5 的滑窗求均值。真正值得聊的是 C 接口下的实现选型，新手最容易写出双重循环：
for (int i = 0; i < n; i++) { float sum = 0; for (int j = 0; j < period && i - j >= 0; j++) sum += in[i - j]; out[i] = sum / period; }这段逻辑没错，但复杂度是 O(n × period)。单界面画图时 3000 根K线没感觉，一旦拿去跑全市场每只股票 5000 根K线的计算，或者周期参数设到 60、120，整体耗时线性放大。更稳的写法是「增量滑窗」：维护一个累加和sum，每往前一根，加入新值、减去窗口最前面的旧值，每个点只需要两次加减法和一次除法。这个技巧在数值计算上还有额外收益——累加顺序固定，结果更稳定。在 C 接口里，多出来的那些if判断粒度，就是决定你的 DLL 能不能扛住实盘选股的地方。
除了滑窗方式，边界处理也是 MA 在 C 接口下必须自己负责的：前period - 1根K线，按数学定义凑不满窗口，内置MA的行为是「无值」（图上不画）。但 DLL 输出缓冲区必须填满所有nNumData个点，你填什么直接决定图形的起点形态。填 0 会把均线起点拉到底部制造假突破信号，填首日开盘价又可能和真实趋势脱节。我一般在实现里先算第一个有效值，然后把前段全部填充为这个值，保证曲线连续、不制造额外拐点。
2.3 用C接口写MA到底图什么：性能、复杂逻辑与边界场景
有人会问：内置MA现成的，我用 DLL 重新写一个不是脱裤子放屁？答案在于「复杂逻辑的扩展性」。你写的第一个 DLL 指标是 MA，但它验证的是一条通路：以后任何公式字母表达不了的东西——比如自定义缠论分型判断、带状态机的突破回踩检测、跨周期引用后的数值修正——都能在这条通路上跑。C 语言能做分支、递归、位运算、调用第三方数值库，这是公式语言给不了的。
性能也不是完全没意义。内置MA是本机优化过的，你的 DLL 想超过它单次运算速度很难，但在两种场景下 DLL 反而占优：一是全市场选股时，你的 DLL 一次调用就能完成多列数据组合计算，减少公式系统内部多次函数调度的开销；二是写复杂算法时，C 代码里可以一次遍历完成滤波和信号判断两件事，公式却要拆成好几个中间变量让系统重复遍历。我把 DLL 指标看作「公式系统的外挂计算器」：简单的活别搬进来，复杂的活非它不可。
3. 从零写一个MA指标DLL：工程配置与核心代码
这一章直接给能编译的最小工程。我建议你新建一个空的 C++ 控制台工程，但把输出类型改成 DLL。下面的代码分成三块：头文件里的结构体定义、插件名导出、以及 MA 计算主函数。先看完整代码，再逐段解释参数。
3.1 导出函数原型与插件名：先让通达信认得你
#define WIN32_LEAN_AND_MEAN #include <windows.h> #include <string.h> typedef struct { int nNumData; // K线数量 int nParam; // 参数个数 float* pParam; // 参数数组，pParam[0] 为周期 float* pData; // 输入数据，如收盘价序列 } PluginCalcData; // 插件名函数：让通达信知道这个 DLL 提供哪些公式 extern "C" __declspec(dllexport) int PluginName(char* name) { strcpy(name, "DEMO_MA"); // 导出名，公式里要原样引用 return 1; } // MA 计算主函数：通达信每次计算指标都会调它一次 extern "C" __declspec(dllexport) int PluginMA(PluginCalcData* calcData, PluginCalcData* pOut) { if (!calcData || !pOut || !calcData->pData || !pOut->pData) return 0; const int n = calcData->nNumData; float* in = calcData->pData; float* out = pOut->pData; int period = 5; if (calcData->nParam >= 1 && calcData->pParam[0] >= 1.0f) period = (int)calcData->pParam[0]; // 增量滑窗：sum 用 double，避免大量累加时 float 精度损失 double sum = 0.0; float firstValid = 0.0f; bool hasValid = false; for (int i = 0; i < n; i++) { sum += in[i]; if (i >= period) sum -= in[i - period]; if (i >= period - 1) { float v = (float)(sum / period); out[i] = v; if (!hasValid) { firstValid = v; hasValid = true; } } else { out[i] = 0.0f; // 前段先占位，随后统一填充 } } if (hasValid) { for (int i = 0; i < period - 1 && i < n; i++) out[i] = firstValid; // 避免前几根为 0 把图形拉平 } return 1; }参数含义拆开看：PluginName里的字符串DEMO_MA是通达信公式里识别插件的名字，必须和公式编辑器里写的名字逐字节一致，大小写也敏感。PluginMA是真正的计算入口，calcData是输入，pOut是输出。返回1表示计算成功，返回0会被通达信当成计算失败，该指标直接不显示。calcData->pParam[0]是公式里写的周期参数，我用if (nParam >= 1)做了保护，防止没传参时越界。
PluginName和PluginMA都加了extern "C"和__declspec(dllexport)。前者保证 C++ 编译器不会对函数名做名字修饰，让导出表里的名字干净；后者告诉链接器把这个函数放进 DLL 导出表。如果漏掉extern "C"，你的导出名可能会变成?PluginMA@@YAHPEAU...@@@Z这种修饰名，通达信按PluginMA找就找不到了。这个细节属于新手最容易翻车的地方。
3.2 计算核心：滑窗求和、前段填充与零除保护
核心循环里有两处容易被忽略。第一处是sum的类型，我故意写成double而不是float。通达信传进来的价格本身是单精度，但如果你的周期参数调到 120 以上，且K线数量几千根，累加过程中小数误差会被放大，最后几位有效数字不稳定，和内置MA对比时会出现肉眼可见的偏离。用double累加再转回float输出，精度损失完全可控。
第二处是前段填充策略。循环里对i < period - 1的区间先写了0.0f，等算完第一个有效值firstValid之后再统一覆盖。这个两步走的写法比直接在循环里判断i - period越界干净得多，也方便你以后换填充策略——比如改成填充in[0]或填充N/A标记。真正上生产环境时，前段怎么填要看你的下游用这个指标做什么：画图用填首个有效值最好，做选股条件用就建议输出一个特殊无效值并在公式端过滤。
周期参数等于 1 或者 0 的情况在代码里也是安全的：period被限制为至少 1，窗口为 1 时 MA 就等于收盘价本身，不会出现除零。如果通达信某次调用传入的参数是个负数（公式写错或者参数越界），pParam[0] >= 1.0f的判断会把它挡在门外，直接走默认周期 5。这种防御性的写法不是为了业务，而是防止 DLL 崩溃导致整个通达信退出，那在实盘环境里是事故级的体验。
3.3 编译与放置：生成DLL后装到哪个目录、怎么验证加载
编译这一步我用最常见的 VS 系 IDE 或 MinGW 都行，关键是输出配置。我个人的习惯是建一个空的 C++ 工程，项目属性里把配置类型从「应用程序」改成「动态库」，字符集用「多字节字符集」。代码里只要包含<windows.h>，就不需要额外链接库。如果你的开发环境是 MinGW，用gcc -shared -o DEMO_MA.dll ma.cpp一行也能编出来，注意在代码里保持extern "C"。
编出Demo.dll之后，把文件复制到通达信主程序所在的目录（和主程序 exe 同一个文件夹）。常见的安装路径下 DLL 要么放主程序根目录，要么放指定的插件目录，不同版本要求不同。我一般复制到根目录后先重启通达信，运行一个最简单的加载测试：在公式编辑器里输入一行TEST:TDXDLL2(1, DEMO_MA, C, 5);，如果副图能画出均线，说明加载成功。
验证导出函数是否正确的命令行手段是 dumpbin。打开 VS 自带的开发者命令行，执行：
dumpbin /exports DEMO_MA.dll输出里应该能看到PluginName和PluginMA这两个未修饰的函数名。如果看到?PluginMA@@...这样的修饰名，说明extern "C"没生效，回去检查工程里是不是开了编译器的名称修饰选项，或者是否用了.c扩展名却在 C++ 工程里编译。这一步检查能在把 DLL 扔进通达信之前拦截掉八成加载失败问题。
4. 在通达信中调用DLL指标：公式写法与参数调试
DLL 编出来了，但这只是第一步。真正让指标在通达信界面里跑起来，公式端的写法也有讲究。这里我把公式编辑器里的写法和 DLL 内部的行为对照着讲清楚，这样你调参时不用两边瞎猜。
4.1 一行公式调起DLL：函数名、数据列与周期参数是怎么对应的
在通达信公式编辑器里，调用 DLL 公式的写法类似下面这行（不同版本可能有差异，以你本机的提示为准）：
MA_DLL:TDXDLL2(1, DEMO_MA, C, 5);这里TDXDLL2是通达信提供的 DLL 调用函数，第一个参数1表示加载编号（如果你装了多个 DLL，编号对应你注册的位置），第二个参数DEMO_MA必须和 DLL 里PluginName导出的字符串完全一致，第三个参数C是数据列，第四个参数5是你要传给 DLL 的周期。通达信会把C这一整列收盘价放进calcData->pData，把5放进calcData->pParam[0]，然后把nNumData设为当前K线数量，调起PluginMA。
参数个数可以扩展到多个。比如你想同时传周期和偏移量，公式写成：
MA_DLL2:TDXDLL2(1, DEMO_MA, C, 5, 2);那么 DLL 里nParam就等于 2，pParam[0]是 5，pParam[1]是 2。你在 DLL 里按数组下标取用就行。注意通达信对参数数量有上限限制，超过上限会直接报调用失败，所以 DLL 端的nParam判断不能省，防止自己越界读取。
常见的一个困惑是：DEMO_MA这个名字和 DLL 文件名要不要一致？答案是文件名影响加载，函数内部导出的PluginName字符串影响公式引用，两者不需要相同。你的 DLL 叫Demo.dll，只要内部PluginName导出DEMO_MA，公式就按DEMO_MA引。文件名只是 Windows 加载 DLL 时的实体标识，和公式里的名字是两套体系，别在调不通时死磕文件名。
4.2 三个必调参数：周期、数据源类型和绘线属性
真正写公式时，有三个参数逃不掉。第一个是周期N，它直接决定 DLL 里窗口长度。我建议周期不要写死，而是通过pParam传入并在公式端用参数调，因为 DLL 每次改动周期都得重新编译，公式端改一个数字就能热切换，调试效率差很多。公式里可以写成N:INPUT或者直接在函数里改数字，看你版本支持哪种参数定义方式。
第二个是数据源类型。上面例子用的是C收盘价，但你完全可以把H、L、O甚至成交量V传给同一个 DLL。不过要确认你的 DLL 里的算法假设：MA 对任何序列都成立，但如果你写的是最高价突破判断，传错数据源会让整个信号失真。我给 DLL 写注释时，会在结构体旁边注明「预期输入为收盘价序列」，防止自己过几个月忘了。
第三个是绘线属性。DLL 返回的是数值序列，默认画在主图上可能是个细线，看不出信号。我自己习惯把 DLL 指标画在副图，或者用COLORSTICK之类着色。这里没有统一标准，核心是记住一个原则：通达信把 DLL 的输出当成普通指标序列处理，所有公式层的绘线修饰符都能叠加使用。什么时候改，取决于你要看的是均线本身还是它派生的信号。
4.3 和内置MA对照验证：误差阈值定多少、怎么看差异曲线
这一步我认为是整个调试流程里最值得做的一步，也是很多人省略的一步。第一次写完 DLL，不要直接拿去选股，先在主图里叠加对比：
MA_内置:MA(C, 5), COLORWHITE; MA_DLL:TDXDLL2(1, DEMO_MA, C, 5), COLORYELLOW; DIF:MA_DLL - MA_内置, COLORGRAY;DIF是两条曲线的差值。肉眼观察黄色和白色曲线是否完全重合，再切换到DIF副图看差值量级。正常情况下，DIF应该在±1e-3以内波动——因为 DLL 用double累加，内置MA用什么精度我不知道，两边在最后几次舍入上会有一点点差异。如果差值达到0.01以上，问题基本出在你的滑窗边界处理上，重点检查前period - 1个点的填充逻辑和sum的加减时机。
还有一个容易忽略的验证点：周期参数传不同值时，DIF 的形态是否一致。比如分别传5、10、60跑一遍，如果某个周期下 DIF 突然变大，往往是该周期下正好踩中越界分支。把这些情况在行情软件里截图留档，以后改代码回归测试时直接用截图对比，比重新复盘公式快得多。
5. 通达信DLL公式避坑：从加载失败到图形翻车的五个记录
DLL 公式这个方向，最大的特点就是「编译时爽、加载时懵」。下面五条是我自己和朋友在开发过程中真实踩过的坑，按出现频率排序。每一条我都按照「现象 → 原因 → 解决」来讲。
5.1 32位与64位不匹配：插件加载失败的第一大原因
现象：DLL 放在正确目录，dumpbin看导出函数也对，但通达信公式编辑器里一用就报「加载失败」或者干脆不显示指标。
原因：通达信软件本身有 32 位和 64 位版本，插件 DLL 的位数必须和主程序完全一致。你手头编译器默认输出 32 位 DLL，放在 64 位通达信里，系统加载时直接拒绝；反过来也一样。而且这个错误不一定弹窗提示，很多时候是静默失败，公式那行显示出来但曲线不画。
解决：先确认通达信主程序位数。打开任务管理器看进程名后面是否带(32位)，或者看安装目录下的主程序文件名是否带x64字样。然后调整你的编译目标：VS 系 IDE 在解决方案配置里选x64，MinGW 用gcc -m64。编译完用 dumpbin 的HEADER选项看一下机器类型，或者直接看生成文件大小——32位 DLL 普遍比 64 位小一截，但最稳妥还是看文件头。
5.2 插件名比对失败：导出名大小写与空格陷阱
现象：DLL 能加载了，但公式引用DEMO_MA时就是画不出东西，日志里也没有任何输出；甚至有时同一台机器上，某一次编译后突然失效。
原因：PluginName里strcpy的字符串和公式里的引用名必须完全匹配，包括大小写和空格。我遇到过 DLL 里写的是"DEMO_MA "（末尾多了个空格）而公式写"DEMO_MA"，肉眼根本看不出区别，但字符串比对就是失败。另外，PluginName函数不是只调用一次，通达信可能在每次计算前都调用它来确认插件存在，所以这个函数里不能有耗时操作。
解决：代码里字符串定义用字面量宏，比如#define PLUGIN_NAME "DEMO_MA"，公式端复制这个宏的字符串，不手敲。改动名字后，重新编译 DLL 前先删掉通达信里加载的旧 DLL，防止 Windows 文件缓存导致用的是旧导出表。如果还不确定，在PluginName里临时加一个OutputDebugString输出实际字符串，用调试器或者 DebugView 看通达信到底拿到了什么。
5.3 前几根K线被拉平：无效值填充的坑
现象：DLL 指标画出来，起点不是从第一根K线开始，而是前面一大段水平直线，且这条水平线的值和后面均线完全不在一个量级；或者整条曲线存在明显的「先平后弯」形态。
原因：这就是我在 3.2 节说的前段填充问题。如果前period - 1个点填 0，而合约价格是几千甚至上万，这条水平线会从坐标底边开始，视觉上把均线的启动段压平；反过来，如果用首个有效值填充但首个有效值本身是异常值，线也会被抬高。还有一个不太明显的坑：某些新手在循环里把前段写成out[i] = out[i-1]，但out[i-1]此时还是未初始化的内存垃圾，画出来是乱跳的毛刺。
解决：按 3.2 的做法，先算第一个有效值，再统一回填前段。如果做选股条件用，需要区分「无值」和「有值」，建议在 DLL 输出一个特殊标记值（比如-9999），然后在公式端用IF(DLL_OUT < -9000, DRAWNULL, DLL_OUT)过滤，这样选股引擎不会把无效值当真信号。注意，通达信某些绘图引擎对特殊值有保留规则，用之前先小范围测试。
5.4 参数被通达信覆盖：你传入的参数地址里可能不是你以为的值
现象：DLL 里读取calcData->pParam[0]得到的周期，和你公式里写的5不一样，有时差一个，有时完全是别的数。更诡异的是，用TDXDLL2(1, DEMO_MA, C, 5, 10)时，第一个参数读出来可能不是 5。
原因：通达信传递参数时，pParam数组的前几个槽位可能被系统内部占用，或者调用编号、公式内其他修饰符被塞进参数区。不同版本之间行为不一致。如果你直接把pParam[0]当成公式写的第一个值，就会出现「读到的数不是你以为的数」。
解决：在 DLL 里养成习惯：先把pParam的前 2 个值打日志或者用输出值回传测试，摸清你所在版本的偏移量。稳妥的做法是不依赖偏移量猜测，而是公式端固定只传一个参数，其余数据用全局参数或别的 DLL 函数传递。我也见过有同行把所有配置合并成一个整数编码，比如周期 5 和偏移 2 编码成502，DLL 内部分解，这样只占一个参数槽，绕开覆盖问题。
5.5 文件占用与缓存：重编译后的DLL总是旧的
现象：改了 DLL 源码，重新编译后放到通达信目录，重启软件，图形没有任何变化，甚至公式提示的版本号也没变。反复确认代码改对了，但结果就是旧的。
原因：通达信启动后会把插件 DLL 加载进进程内存，文件被锁定。虽然你复制了新文件覆盖成功，但进程内使用的还是旧模块副本。更麻烦的是，某些情况下通达信会缓存插件的加载结果，即使重启也可能从系统缓存里读取旧文件。我自己遇到过一次：编译时间戳变了，但通达信加载的还是上一次的，最后发现是杀毒软件把新 DLL 隔离了，用的是隔离前的副本。
解决：改完 DLL 后，先确认通达信完全退出（进程列表里没有相关进程），再覆盖文件，再启动。如果还不生效，把旧 DLL 删掉后再粘贴新文件，避免系统文件缓存直接命中。还有一个习惯很值得做：在PluginName里附加一个版本号字符串，公式端通过某种方式显示出来，调试时一眼就能确认当前加载的是哪个版本，省掉很多「是不是没拷进去」的自我怀疑。
6. 进阶：让MA插件有资格跑全市场选股的三个习惯
DLL 能画图只是及格，能扛全市场选股才算真正能用。这里分享三个我自己坚持的习惯。
第一件事不是优化循环，而是先写日志。DLL 对通达信是个黑匣子，出问题你完全看不到中间态。我习惯在 DLL 里留一个开关控制的日志函数，计算时把周期、数据量、前几个输出值写到本地文件。全市场跑一遍后打开日志看数值分布，比在通达信里反复画图猜问题高效太多。日志只在你调试时打开，上线时关掉，否则全市场选股会写出几百 MB 文件。
第二件事是确认你的算法复杂度配得上市场。MA 的增量滑窗在 O(n) 下能轻松扛几万根K线，但如果你把 DLL 改成嵌套循环处理大周期，全市场 5000 只股票、每只 3000 根数据，总计算量会瞬间上来。我的经验是：任何 DLL 指标，单次调用超过 10 毫秒就要警惕；超过 100 毫秒基本是算法写砸了，先优化再谈功能。
第三件事是从 MA 抽象出通用的滤波接口。实现一次 MA 后，EMA、SMA 无非是加权系数的差别。我会在 DLL 里留一个算法类型参数，公式端传 1 算 MA、传 2 算 EMA，这样每次新增算法不用换 DLL，公式层改个参数就行。这个抽象带来的额外收益是不动算法的情况下，前段填充、日志、参数保护都是同一套代码，维护成本低很多。
我自己的教训是：第一次写 DLL 公式时太自信，跳过日志直接全市场跑选股，结果选出几百只错误信号，排查了一整天才发现问题出在前段填充。那个下午之后，我所有插件代码第一行必定是日志开关。这个习惯替我挡掉了后续几乎所有的拟真事故。希望这些经验能帮你在通达信 DLL 公式这条路上少走几步弯路。
本文还有配套的精品资源，点击获取
