企业官网建设流程全解析

简介：面向股票软件二次开发者的WIN32动态链接库接口模板，聚焦大智慧新一代公式系统外部扩展函数的C语言实现，提供可直接参考的工程骨架，适合具备C++基础、希望为行情终端接入自定义指标或功能模块的开发者使用。整个压缩包仅6KB，共6个文件，以2个cpp源文件和2个h头文件为核心，配合dsw工作区与dsp工程文件，便于在VC环境中直接打开、编译与二次修改；源码与头文件分工明确，工程配置也一并保留，省去从零搭建DLL项目的繁琐。已有1892人学习下载，说明其在公式接口与外部函数扩展场景中具有一定参考价值。读者可从中了解外部扩展函数的声明与导出方式、StdAfx预编译头的组织以及最小化DLL工程结构，既能作为调试接口调用、排查编译链接问题的起点，也便于将模板迁移到自己的公式扩展项目中，减少重复搭建环境的时间。

1. 行情终端里的 C 语言接口：公式不够用的那一步

写公式写到第三年，总会撞上一堵墙：均线、MACD、布林这些内置函数随便拼，可一旦要做跨周期校验、要读外部因子文件、要在公式里调用自己写的数值优化器，公式语言就彻底不够用了。行情分析终端提供的 C 语言接口，本质是把公式引擎的计算权交一部分出来——你编译一个动态库，导出符合约定的函数，公式里就能像调用 MA、EMA 一样调用它。这套 C++ 公式接口面向的是有 C/C++ 底子、需要把私有算法塞进行情终端的人：做量化信号验证的、要复用已有 C 库的、嫌公式语言跑得慢的。下文统一用 DG 终端指代这类行情分析终端，接口细节按通用约定描述，具体版本以随包头文件为准。

2. 接口签名定生死：调用约定、参数指针与导出表

接口设计里最容易拍脑袋、也最容易在半年后翻车的部分，就是函数签名。行情终端调用你的 DLL 时，它不知道你内部用了几个类、几个模板，它只知道一个函数地址、三个参数、一个 double 返回值。任何超出这个约定的东西——异常、C++ 对象、STL 容器、跨 DLL 的 new/delete——都会在某个用户的机器上炸掉，而且往往炸在终端进程里，连带用户正在看的行情一起没了。

所以第一件事不是写算法，是把契约头文件钉死。我的习惯是先写一个dgfunc.h，让 DLL 工程和自测宿主工程共用它，任何一方改动都必须同步重新编译两边。

2.1 三个参数定架构：参数个数、参数数组、计算上下文

宿主的调用模型通常是这样的：公式里写了一行MYMA(CLOSE, 20)，引擎解析出函数名MYMA、参数个数 2，然后按 K 线逐根调用你导出的函数，每次告诉你"现在算到第几根"。序列数据不通过参数数组传，而是放在一个只读上下文结构体里，由宿主填充。

/* dgfunc.h —— 公式函数接口的唯一契约头文件，DLL 与自测宿主共用 */ #ifndef DGFUNC_H #define DGFUNC_H #ifdef __cplusplus extern "C" { #endif /* 32 位宿主必须 __stdcall；64 位下该修饰被忽略，但保留写法便于两套二进制共存 */ #ifdef _WIN32 # define DG_CALL __stdcall #else # define DG_CALL #endif /* 计算上下文：宿主填充，DLL 只读。禁止修改内容，禁止把指针存起来下次用 */ typedef struct tagDGCalcCtx { int nDataLen; /* 当前数据集 K 线总根数，可能随时变化 */ int nCurIndex; /* 本次调用的位置，0 表示第一根 K 线 */ const double* pOpen; /* 以下序列长度均等于 nDataLen，可能为 NULL */ const double* pHigh; const double* pLow; const double* pClose; const double* pVol; int nPeriod; /* 周期标识，日线/分钟线由宿主给出，仅作参考 */ void* pReserved; /* 保留字段，必须忽略，不要强转成任何结构体 */ } DGCalcCtx; /* 导出函数的统一签名，公式端按导出名调用 */ typedef double (DG_CALL *PFN_DG_CALC)(int nParamCount, const double* pParams, const DGCalcCtx* pCtx); #ifdef __cplusplus } #endif #endif

三个参数的分工要背下来：nParamCount是公式里实际写了几项，pParams是这封装换好的 double 数组（含第一项，通常用来传序列或标量），pCtx是行情数据和时间位置的唯一来源。

几个参数上的血泪经验值得单独说。nParamCount一定要做上下界双重校验，公式作者写错参数个数是家常便饭，少传一个你按pParams[1]取值就是越界读，多传一个你少读一项也不报错但结果对不上。pCtx->nDataLen不是常量，用户切换周期、切换品种、拉长历史区间都会变，任何长度的缓存都要带版本号或长度戳。pReserved现在没用不代表以后没用，我在代码评审里见过有人把它强转成自家结构体然后写数据进去——这种写法能跑，直到宿主换版本。

提示：pOpen/pHigh/pLow/pClose/pVol允许为 NULL。分钟线、自定义品种、指数合成数据里缺字段的情况真实存在，取值前先判空，缺数据就返回空值，别拿 0 顶上去算。

2.2 调用约定与位数：比算法更容易翻车的地方

__stdcall和__cdecl的区别在教科书上是"谁负责清栈"，在真实项目里是"终端闪退还是正常出数"。32 位宿主按__stdcall调用，你导出的是__cdecl，栈指针一错，函数返回的那一刻整个进程就没了，而且没有任何异常信息，只有一个 Windows 错误报告框。这类问题极难从现象反推，因为崩的地方离真正的原因十万八千里。

位数问题同理。宿主是 32 位进程，你编了个 64 位 DLL，LoadLibrary会直接失败，公式端看到的是"函数不存在"。反过来也一样。所以工程的第一条纪律是：编译前先确认宿主进程的位数，在任务管理器里看一眼就行，别猜。

/* 用 C++ 写实现、用 C 暴露接口的标准写法 */ #include "dgfunc.h" #include <cmath> #include <vector> #include <string> namespace { /* 内部随便用 STL、用类、用异常，只要不跨过下面的 extern "C" 边界 */ struct WindowStat { double mean = 0.0; double stdev = 0.0; }; WindowStat calc(const double* p, int n) { WindowStat s; for (int i = 0; i < n; ++i) s.mean += p[i]; s.mean /= n; for (int i = 0; i < n; ++i) { const double d = p[i] - s.mean; s.stdev += d * d; } s.stdev = std::sqrt(s.stdev / n); return s; } } /* 唯一需要导出的入口，C 链接、noexcept、只接收 POD */ extern "C" __declspec(dllexport) double DG_CALL MYSTD(int nParamCount, const double* pParams, const DGCalcCtx* pCtx) noexcept { try { if (!pCtx || !pCtx->pClose) return 0.0; const int i = pCtx->nCurIndex; if (i < 0 || i >= pCtx->nDataLen) return 0.0; int n = (nParamCount >= 2) ? static_cast<int>(pParams[1]) : 20; if (n < 2) n = 2; if (n > 2000) n = 2000; /* 上限保护，公式里写 999999 的人不少 */ if (i + 1 < n) return 0.0; /* 数据不足返回空，不要瞎算 */ return calc(pCtx->pClose + (i - n + 1), n).stdev; } catch (...) { return 0.0; /* 异常绝不能穿越 C ABI 边界 */ } }

这段代码的关键不在算法，在边界处理：extern "C"禁止名字修饰（否则公式里写的名字永远匹配不上），noexcept加 try/catch 兜底（异常穿过 C 边界是未定义行为，实际表现是进程直接死），参数上下界收紧，数据不足时返回空值。

2.3 从源码到 DLL：一份能编译通过的最小工程

导出名要和公式里写的完全一致，最稳妥的方式是用.def文件显式声明，而不是依赖__declspec(dllexport)自动修饰——后者在 32 位下会把__stdcall的名字修饰成_MYSTD@12这种形式，公式引擎按MYSTD找，自然找不到。

; mystd.def —— 显式导出，屏蔽名字修饰带来的匹配问题 LIBRARY MYSTD EXPORTS MYSTD

# 32 位 Release 构建（位数必须与宿主进程一致） cl /nologo /LD /O2 /W3 /EHsc /D_CRT_SECURE_NO_WARNINGS \ mystd.cpp /link /DEF:mystd.def /MACHINE:X86 /OUT:MYSTD.dll # 检查导出表，确认名字干净、没有 @ 修饰 dumpbin /exports MYSTD.dll

/LD生成 DLL，/O2开优化（公式函数会被逐根 K 线调用几十万次，Debug 版慢到没法用），/MACHINE:X86强制 32 位，/DEF挂上导出脚本。dumpbin /exports是每次打包必跑的检查项：输出里如果看到_MYSTD@12而不是MYSTD，别上传，先回去改导出方式。

工程组织上，我一般会再建一个host_test子工程，静态链接同一份.cpp，用假数据跑一遍再进终端。原因很实际：终端里调试 DLL 基本靠日志和猜，宿主进程崩了连调用栈都拿不到，把问题前移到可控环境里成本低一个数量级。

3. 数据打通：double、字符串、序列与空值

签名对上只是能加载，能不能算出对的结果，取决于你对数据类型的处理是否和宿主的预期一致。公式引擎的类型系统比 C 简单得多，它只有数值、字符串、序列、空值四类东西，映射到 C 接口上各有各的坑。

3.1 数值是硬通货：int、bool、NaN 的边界

所有参数进来都是double，所有结果出去也是double。看似简单，但类型语义得自己守：公式里的整数参数要先static_cast<int>再校验范围，直接拿double去比较n < 1在n = 0.9999999时会误判；布尔返回值按惯例用 1.0 和 0.0，不要返回 -1.0 当 false，公式端做IF(条件, A, B)时只认非零。

空值是重灾区。公式引擎里"这根 K 线没有值"和"这根 K 线的值是 0"是两回事，前者在图上表现为断线，后者是一条贴着零轴的实线。C 接口里通常用 NaN 表达空值，所以你的函数在数据不足、除零、开方负数、对数非正的时候，应该return std::nan("")而不是return 0.0。

注意：NaN 有个特性是NaN != NaN恒为真，用它做判断必须写if (v != v) return NaN;。但千万别在累加循环里放过 NaN，一个 NaN 进来整个和就废了，而且不会报错，只会静默输出一条断线，排查起来非常熬人。

还有一个容易被忽略的点：double精度。行情价格一般是两位小数，但中间计算（比如协方差、回归斜率）会放大误差，最后再拿去和公式里的阈值比较时，0.30000000000000004 > 0.3成立，信号就多了一个。涉及阈值判断的地方，我会显式加一个 1e-9 量级的容差，宁可少一个信号，也不要一个逻辑上说不清的多余信号。

3.2 字符串参数：谁分配谁释放

字符串参数普遍采用"两次调用"模型：第一次传入空缓冲区和 0 长度，函数返回所需字节数；宿主按这个长度分配缓冲区，第二次调用把数据拷进去。这套模型的好处是不用约定内存分配器，坏处是很多人只实现了一半。

/* 两次调用模型：szBuf 为 NULL 时只查询长度，不写任何数据 */ extern "C" __declspec(dllexport) int DG_CALL MYSTR(int nParamCount, const double* pParams, char* szBuf, int nBufLen) noexcept { static const char kText[] = "DG-CUSTOM-1"; /* 只读常量，生命周期无限长 */ const int nNeed = static_cast<int>(sizeof(kText)); /* 含结尾 0 */ if (szBuf == 0 || nBufLen <= 0) return nNeed; /* 第一次：只报长度 */ if (nBufLen < nNeed) return nNeed; /* 缓冲区不够，仍报真实需求 */ for (int i = 0; i < nNeed; ++i) szBuf[i] = kText[i]; return nNeed; }

要点在于：长度包含结尾的\0；nBufLen不够时不要截断写入，直接返回所需长度让宿主重试；返回的字符串绝不指向函数内部的局部变量或std::string::c_str()——函数一返回那块内存就没了，宿主读到的是野指针内容，运气好是乱码，运气差是崩溃。

如果确实需要返回动态生成的字符串，就在 DLL 里用一块静态缓冲区自己管生命周期，并且明确约定"下一次调用会覆盖上一次的内容"。这个约定要在头文件注释里写清楚，别指望后来接手的人能猜出来。

3.3 序列数据与逐K线调用模型

理解逐 K 线调用模型，是写出正确函数的前提。宿主不是把你的函数当成一个黑盒一次性喂完所有数据，而是从第 0 根 K 线开始，一根一根地调：nCurIndex = 0调一次，= 1调一次，直到最后一根。每次调用你只负责回答"在当前这根上，结果是多少"。

这个模型带来两个直接后果。第一，你的函数必须对任意nCurIndex都返回正确值，包括刚开始数据不足的前几根。第二，任何跨 K 线的状态（比如递归平滑、累计量）都不能存在函数静态变量里——用户切换周期时引擎可能重新计算，静态变量的残留值会让你输出的曲线在切换后的前几十根上完全错乱。这类 bug 在图上表现为"切换周期后指标头一段是平的"，很难联想到是状态没清。

/* 序列相关的正确写法：所有跨 K 线信息都从 pCtx 重新推导，不留静态状态 */ extern "C" __declspec(dllexport) double DG_CALL MYSUM(int nParamCount, const double* pParams, const DGCalcCtx* pCtx) noexcept { if (!pCtx || !pCtx->pClose) return 0.0; const int i = pCtx->nCurIndex; int n = (nParamCount >= 2) ? static_cast<int>(pParams[1]) : 5; if (n < 1) n = 1; if (i + 1 < n) return 0.0; double sum = 0.0; for (int k = 0; k < n; ++k) { const double v = pCtx->pClose[i - k]; if (v != v) return 0.0; /* NaN 短路，避免污染整段结果 */ sum += v; } return sum; }

这段的复杂度是 O(n) 每根 K 线，总体 O(N·n)，在 n 小的时候完全够用。真正上线上量之后才会发现，一个 5000 根历史、窗口 250 的函数，用户点一次刷新要跑一百多万次循环，体感上就是"这个指标一加进去软件就卡"。性能优化放在第 6 章展开。

3.4 异常不能穿过 C ABI

C++ 的异常机制依赖编译器生成的栈展开表，跨 DLL 边界抛出时，如果两边编译器版本、运行库配置、异常模型不一致，结果是未定义行为。实际观察到的现象是：函数里抛了个std::out_of_range，宿主进程无声无息地消失，事件查看器里只有一条"应用程序错误"。

所以导出函数的骨架应该是固定的：最外层noexcept，函数体整体包在try { ... } catch (...) { return 空值; }里。内部可以随便用异常做控制流，只要它在边界内被吃掉。这个 catch 不是"防御性编程"的装饰，是保命的。

同理，std::string、std::vector、任何带析构函数的类型都不能出现在导出签名里。宿主的调用栈上根本没有你的析构逻辑，跨堆分配和释放更是禁忌——你的 DLL 用一份 CRT，宿主用另一份，new出来的指针传过去让宿主delete，堆管理器直接报错。内存谁分配谁释放，这条纪律没有例外。

4. 联调：注册、命名匹配与独立宿主自测

DLL 编出来了，公式里还是提示找不到函数，这是最常见的求助场景。九成情况下问题不在算法，在加载环节。把联调拆成"注册→命名→调用"三段查，比在终端里一遍遍重启快得多。

4.1 注册与名字匹配

DG 终端这类宿主一般要求在设置里指定 DLL 的完整路径，然后重启或刷新公式引擎，引擎才会去LoadLibrary并枚举导出表。这里有三个独立的失败点，任何一个不满足都会报"函数不存在"，错误信息却完全一样。

第一是路径。相对路径在不同工作目录下解析结果不同，一律写绝对路径，并且路径里不要有中文和空格——不是所有版本的宿主都用宽字符 API 加载，遇到中文路径可能直接失败。第二是位数，前面说过，32 位宿主加载 64 位 DLL 必失败。第三是导出名，公式里写的MYSTD，导出表里必须是MYSTD，多一个下划线、多一个@12都算不匹配。

我的排查顺序是固定的：先dumpbin /exports看名字，再确认 DLL 位数和宿主一致，最后才去查路径和注册。顺序反了会白折腾很久，因为"重启终端"这个动作太廉价，容易让人反复重启而忘记做静态检查。

提示：把 DLL 放到终端安装目录下再注册，能规避一部分搜索路径问题。但升级终端时这个目录可能被覆盖或清理，长期方案还是放在独立目录、注册绝对路径。

4.2 写一个独立宿主程序先跑通

在终端里调试 DLL 的体验极差：没有断点、没有调用栈、崩了只有一句"程序已停止工作"。所以我的习惯是永远先写一个几十行的自测宿主，用假数据把函数跑通，再进终端。

/* host_test.c —— 独立自测宿主，把联调问题挡在终端之外 */ #include <windows.h> #include <stdio.h> #include <math.h> #include "dgfunc.h" int main(void) { HMODULE h = LoadLibraryA("MYSTD.dll"); if (!h) { printf("LoadLibrary failed: %lu\n", GetLastError()); return 1; } PFN_DG_CALC fn = (PFN_DG_CALC)GetProcAddress(h, "MYSTD"); if (!fn) { printf("GetProcAddress failed: %lu\n", GetLastError()); return 2; } /* 造 300 根模拟收盘价，避免依赖真实行情 */ double close[300]; for (int i = 0; i < 300; ++i) close[i] = 10.0 + (i % 17) * 0.13; DGCalcCtx ctx = {0}; ctx.nDataLen = 300; ctx.pClose = close; ctx.nPeriod = 0; double params[2] = { 0.0, 20.0 }; /* [0] 占位序列，[1] 窗口长度 */ int nBad = 0; for (int i = 0; i < 300; ++i) { ctx.nCurIndex = i; double v = fn(2, params, &ctx); if (v != v) { ++nBad; continue; } /* NaN 计数，正常应集中在前 19 根 */ if (i == 299) printf("last=%f\n", v); } printf("NaN count=%d (expect 19)\n", nBad); FreeLibrary(h); return 0; }

这个宿主干了三件事：验证LoadLibrary和GetProcAddress能否成功（这是名字和位数问题的照妖镜）、用可控数据验证数值正确性、统计 NaN 出现的位置是否符合"前 n-1 根数据不足"的预期。第三点特别有用——如果 NaN 出现在中间而不是开头，说明函数内部有分支没处理好，或者访问了越界内存。

编译它的时候注意同样要用 32 位：cl /MACHINE:X86 host_test.c。这个工程编错位数，症状和 DLL 编错位数一模一样，会让你怀疑人生。

4.3 日志与可观测性

终端里的 DLL 出问题，唯一能带出来的信息就是你主动写进去的。所以关键路径上要有日志，但日志本身不能成为性能瓶颈——逐 K 线调用几十万次，每次都fopen/fprintf/fclose会让整个指标慢十倍。

我一般用两种手段。轻量的用一个进程内的环形缓冲，把最近 N 条记录存内存里，另导出一个DUMPLOG函数，公式里单独跑一次把它写到文件。重一点的用OutputDebugStringA，配个调试器看实时输出，不影响正常运行。两者都只在异常分支和首次调用时写，正常路径一条不写。

日志内容上，最有价值的不是"我算出了什么"，而是"我收到了什么"：nParamCount、pParams前几项、nCurIndex、nDataLen、指针是否为空。这套信息能解释 80% 的"结果不对"类问题——多数时候是参数传错了，不是算法写错了。

5. 避坑与排查：五个翻车现场

5.1 公式提示"函数不存在"，但 DLL 明明编出来了

现象：设置里注册成功，公式编辑器里一调用就报错，或者干脆没有任何反应。

原因：按发生频率排，依次是导出名带修饰（_MYSTD@12）、DLL 位数与宿主不一致、路径含中文或空格、宿主没重启导致旧 DLL 还在内存里（被占用时文件替换会失败，但很多人没注意）。还有一种隐蔽情况：DLL 依赖了某个运行库 DLL，加载时因缺少依赖而失败，LoadLibrary返回 NULL，但错误被宿主吞掉了。

解决：先dumpbin /exports确认导出名干净；再dumpbin /dependents看依赖是否都能找到；用 4.2 的自测宿主独立验证一次加载；最后才去查路径。全部通过说明问题在宿主侧，重启后再试。依赖问题我在一台干净机器上遇到过一次，本机装了开发环境所以不缺运行库，换机器就挂，后来改成静态链接运行库才彻底解决。

5.2 一加进公式，终端直接闪退

现象：公式里写上函数名，回车，终端进程消失，没有任何提示。

原因：绝大多数是调用约定不匹配。32 位下宿主按__stdcall调，你导出__cdecl，函数返回时栈指针错位，进程当场死。其次是数组越界写——比如把pParams[1]当长度去写缓冲区，实际公式只传了一个参数。第三是导出函数里抛了异常且没被捕获。

解决：检查头文件里的DG_CALL是否真的落在了导出函数上（见过只在 typedef 里加了、实现里忘了加的）；在函数入口打印nParamCount和nBufLen类参数，确认和公式里写的一致；最外层无条件加try/catch(...)。这条我踩过一次，花了整整一个下午，最后发现是.def文件里写了名字但源码里DG_CALL被宏覆盖掉了。

5.3 结果全是 0，或者整条线是断的

现象：公式能跑，图上一条平线贴着零轴，或者干脆什么都不画。

原因：pCtx判空直接用 0 兜底、nDataLen和nCurIndex关系搞反、取值时用了pCtx->pClose[nCurIndex]但序列指针实际为 NULL（分钟线常见）、数据不足时返回 0 而不是 NaN 导致"有值但都是 0"。还有一种：参数索引错位，把窗口长度读成了第 0 项。

解决：先确认返回值语义——数据不足返回 NaN，真实计算才返回数值。然后逐个打印nParamCount、pParams[0..n]、nCurIndex、nDataLen，和公式里写的对照。序列指针为 NULL 时不要硬算，直接返回 NaN，让图上断线而不是画一条假线。

5.4 切换周期后，指标头一段明显不对

现象：日线切到 60 分钟，或者切换品种后，指标最前面几十根的值和预期完全不符，后面的又正常。

原因：函数里用了静态变量或全局变量保存跨 K 线的累加量。引擎切换周期时会重新从第 0 根开始算，但静态变量还留着上一次的残留值，于是头几根的计算被污染。

解决：把所有跨 K 线状态从静态变量里清出去，改成每根 K 线从pCtx重新推导（必要时用滑动窗口重算）。如果确实需要缓存加速，缓存必须带数据集标识（长度 + 周期 + 首值指纹），不匹配就整块丢弃重建。这个坑我在第 6 章会再给一套缓存方案。

5.5 历史数据一拉长，终端就卡住

现象：默认几百根 K 线时飞快，用户把历史数据拉到几千根，整个界面卡住十几秒。

原因：逐 K 线调用 × 每根内部 O(n) 循环 = O(N·n)，N 是 K 线总数。5000 根、窗口 250，就是 125 万次乘法加 125 万次内存访问，每根还要重复一遍，实际执行量远超直觉。

解决：能用增量就用增量——滑动窗口求和只需要"加一个减一个"，复杂度降到 O(N)；不能增量的用缓存 + 版本号；实在复杂的在首次调用时一次性算完整条序列存进缓冲区，后续直接按下标取。缓存要注意容量上限，别为了一个指标吃掉几百兆内存。

6. 进阶：把逐K线调用压成一次计算

性能优化这块我吃过一次实打实的教训：一个看起来只有十几行的函数，因为每根 K 线都重算整段窗口，在用户拉满历史数据后把终端拖到无响应。后来改成增量维护，同样的计算量从十几秒降到基本无感。核心思路是把"每根 K 线重新推导"换成"缓存 + 增量更新"，但缓存必须带失效条件。

/* 增量版滑动求和：缓存带数据集指纹，指纹变化即整体重建 */ extern "C" __declspec(dllexport) double DG_CALL MYSUM_FAST(int nParamCount, const double* pParams, const DGCalcCtx* pCtx) noexcept { static thread_local struct { int nLen = -1, nPeriod = -1, nWindow = -1; double dFirst = 0.0; double dLast = 0.0; /* 当前窗口和 */ } cache; try { if (!pCtx || !pCtx->pClose) return 0.0; const int i = pCtx->nCurIndex; int n = (nParamCount >= 2) ? static_cast<int>(pParams[1]) : 5; if (n < 1) n = 1; if (i + 1 < n) return 0.0; /* 数据集指纹：长度、周期、首值任一变化都视为换了一份数据 */ const bool bSame = (cache.nLen == pCtx->nDataLen) && (cache.nPeriod == pCtx->nPeriod) && (cache.nWindow == n) && (cache.nLen > 0 && cache.dFirst == pCtx->pClose[0]); if (!bSame || i == n - 1) { double s = 0.0; for (int k = 0; k < n; ++k) s += pCtx->pClose[i - k]; cache = { pCtx->nDataLen, pCtx->nPeriod, n, pCtx->pClose[0], s }; return s; } /* 增量：加上新的一根，减掉窗口末端之外的那一根 */ cache.dLast += pCtx->pClose[i] - pCtx->pClose[i - n]; return cache.dLast; } catch (...) { return 0.0; } }

thread_local是因为公式引擎可能在多线程里跑不同品种，全局静态会被并发写乱；指纹里的三个字段用来判断是否换了数据集；i == n - 1是增量链条的起点，必须整段重建一次，否则累加基准是错的。这套写法收益明显，但引入了"缓存不一致"这个新的故障类别，所以上线前我把下面这张表走了一遍。

从那以后我每次交付前都强制走一遍这张表，尤其是"切换周期后头段"和"拉满历史数据计时"这两项——它们不报错，只在用户手里慢慢暴露，等反馈回来复现成本已经翻了几倍。把这两项变成肌肉记忆，比事后加十行日志都管用。希望帮到你。

本文还有配套的精品资源，点击获取