企业官网建设流程全解析

先交代一下这个项目是怎么来的。我维护的技术面筛选流程，之前一直是"看几只算几只"：从行情软件里导出一个股票池，逐只算指标，大概二三十只票，循环里跑半天也不觉得慢。直到某次要求"把全市场都过一遍"——沪深两市五千多只股票，每只都要输出51个技术指标的当前值，还要按指标做截面排序，我才意识到单票分析和全市场扫描根本是两个物种。

接到这个需求，第一反应是算算量：5000只股票 × 51个指标，就是25.5万个指标值。听着吓人，但每只股票只算最新一个交易日的话，数据量其实很小，难点根本不在计算量，而在于三个地方：一是指标之间有大量重复的底层计算，直接逐股跑等于把同一批EMA算了五千遍；二是全市场扫描对数据质量极其敏感，停牌、新股、ST、除权、一字板全都混在一起，清洗规则写不好，后面所有指标都是脏的；三是跑出来25万个数字怎么落地、怎么查、怎么变成能用的信号，也需要单独设计。

这篇文章把我从零搭这套扫描系统的完整过程梳理一遍，包括指标依赖分层的思路、数据清洗和存取方案、三种计算路线的实测对比、结果存储与信号聚合的做法，以及最后对拍核验时踩到的一堆坑。适合正在做或准备做全市场技术面扫描的人参考，也适合只想把几百上千只股票批量算指标的人——这里面的很多坑，股票一多就会遇到。

1. 先想清楚：全市场扫描到底难在哪

1.1 单票分析和全市场扫描是两个物种

单票分析的本质是"深挖"。你有一只有兴趣的票，把它的日线拉到屏幕上，鼠标点上几个指标，看看形态、看看背离，几秒钟就能完成。这个场景里，数据是干净的，指标是单只股票独立算的，你甚至不用关心其他四千多只股票在干什么。

全市场扫描的本质则变成了"宽筛+标准化"。同一个指标要在五千多只股票上得到可比的数值，然后横向排序、过滤、打分。这个转变带来的问题很直接：

第一，数据结构不一样。每只股票因为上市时间不同、停牌天数不同，可用的历史窗口完全不同。次新股上市才20天，你给它算250日均线，结果当然是空的；停牌半年的股票，复牌当天跳空，指标序列会出现断层。

第二，计算的粒度不一样。单票分析可以容忍循环里每次都重算一遍MA、EMA这种基础序列，全市场扫描如果每个指标都从原始价格重新推导，等于把最底层的平滑计算重复执行了几百上千次，纯粹是浪费机器和时间。

第三，结果必须可解释、可追溯。你说"今天有87只股票出现MACD金叉"，这个数字是怎么来的？用的哪套参数？复权方式是什么？NaN是怎么处理的？如果答案模糊，这个结果就没人敢信。单票分析可以拍脑袋，全市场扫描的结论经常要拿去指导决策，含糊不得。

所以我在动手之前先定了一条规矩：整个扫描过程必须幂等、可复现、可对拍。同一份数据，不管跑多少遍，输出的每只股票每个指标的值必须一模一样。

1.2 51个指标不是拍脑袋凑数，而是筛选体系的组合

这51个指标不是某一天从哪份研报里抄来的，而是我从日常筛选逻辑里反推出来的。平时看盘用到的指标大致分五类，分类如下：

粗算下来，传统技术分析里常用且有明确公式的指标大概就是四五十个，再把参数变体补上，凑到51个顺理成章。这一步看似简单，其实很重要：指标清单一旦确定，后面所有工作——依赖分析、计算管线、结果表结构、对拍脚本——都围绕它展开。建议不要今天加一个明天删一个，先把清单当合同定下来。

1.3 给系统定个合理目标：每天收盘后30分钟内出结果

A股下午3点收盘，数据接口通常在下午4点到6点之间把当日数据补全。我的目标定得很朴素：数据到位后30分钟内，系统必须输出全市场各指标的当日快照、截面排名和筛选候选清单。

这个目标决定了技术选型的方向。半小时看起来宽松，但如果采用逐股循环调指标库的方案，5000只股票乘51个指标，光函数调用就是25万次，加上数据读取和结果落盘，很容易跑到十几分钟甚至半小时以上。再加上数据清洗、输出Excel这些杂活，time budget就非常紧张。所以我在设计之初就把"计算速度"当作一等公民，而不是跑通了再优化。

2. 51个指标背后的依赖树：先算谁，能省一半时间

2.1 把指标拆成"底座—中层—上层"三层

很多人写指标扫描喜欢这样：ma5 = 算一遍均线，ma10 = 再算一遍均线，macd = 从原始价格算EMA12、EMA26……写下来一百来行，全是从原始行情出发的独立计算。功能上没错，性能上惨不忍睹——同一批EMA被重复算了十几遍。

我梳理完这51个指标的公式后发现，它们根本不是51个并列的独立计算，而是一棵有向树。绝大多数指标都建立在几个非常基础的底座序列上：

• 价格平滑底座：收盘价的MA、EMA；
• 波动底座：最高最低价的滚动极值、真实波幅TR、滚动标准差；
• 量能底座：成交量滚动和、成交额滚动和、价量乘积序列。

中层是这些底座的直接产物，比如RSV、DIF、DEA、TR、乖离率、强弱比值。上层才是大家真正挂在嘴边的MACD柱、KDJ的K/D/J、ATR、ADX、价格通道。

这条推断直接改变了我的实现方式：先把5类底座序列全部算好、缓存住，任何上层指标一律从底座读取，而不是从头算。

2.2 一个具体的例子：MACD和TRIX共享同一批EMA

拿MACD举例。国内行情软件里的标准公式是：

• DIF = EMA(CLOSE, 12) - EMA(CLOSE, 26)
• DEA = EMA(DIF, 9)
• MACD柱 = 2 × (DIF - DEA)

EMA是一个递归平滑，公式是：

EMA_today = EMA_yesterday + 2/(N+1) × (close_today - EMA_yesterday)

稍微算一下就知道，MACD需要三个EMA序列：EMA12、EMA26、EMA9(DIF的平滑)。而TRIX这个指标，它的标准算法是：

• TR = EMA(EMA(EMA(CLOSE, N), N), N)
• TRIX = (TR_today - TR_yesterday) / TR_yesterday × 100

看到没有，TRIX内部也是三重EMA。如果逐股循环时每个指标都独立算一遍，MACD要算3个EMA，TRIX又要算3个EMA，光这两个指标就重复计算了6次同周期的平滑。全市场5000只股票放大一下，纯计算量翻两三倍都不止。

所以我在底座层统一提供EMA、MA、TR、滚动极值、滚动标准差的接口，上层指标一律调用底座结果。这部分的收益在5000只股票的规模下特别明显，后面实测数据里能看得清清楚楚。

2.3 中国式指标的"方言"问题，必须单独处理

这是全市场扫描里最隐蔽、也最容易让结果对不上号的坑。开源指标库里实现的指标，和国际通用教科书版本一致，但国内行情软件里的公式有好几个都带"中国特色"，直接调用开源库会得到有偏差甚至完全不同的数值。

最典型的是KDJ。国内软件的标准公式是：

• RSV = (CLOSE - LLV(LOW, 9)) / (HHV(HIGH, 9) - LLV(LOW, 9)) × 100
• K = SMA(RSV, 3, 1)
• D = SMA(K, 3, 1)
• J = 3 × K - 2 × D

这里SMA(X, N, M)不是简单移动平均，而是一种带权重的递归平滑：

Y_today = (M × X_today + (N - M) × Y_yesterday) / N

当M=1、N=3时，就是 Y = (X + 2 × Y')/3。这个算法和开源库里的SMA（简单移动平均）完全是两回事，如果直接拿开源库的SMA去套，KDJ的K值和D值全都会偏。

类似的还有MACD柱是否乘以2、RSI的平滑方式、CCI公式里的0.015常数、ATR是用Wilder平滑还是用递归SMA。这些差异单独看都是小数点后的事，但放到全市场扫描里，含义就差远了——金叉还是死叉的判断可能直接翻转。

我的处理办法是：凡是国内行情软件有标准公式的指标，全部用numpy/pandas手写实现，不依赖开源指标库。手写一开始有点工作量，但换来的是对拍时干干净净的数值，这个账算得过来。

3. 数据地基：5000只股票的历史数据怎么清洗、复权、存储

3.1 日线数据的获取与字段设计

全市场扫描的第一步是数据。A股全市场大概5000多只股票，单看日线数据量其实不大：一只股票一年约250根日K，10年2500根，5000只股票也就1250万行，一个中等配置的笔记本内存完全装得下。

数据源我选了开源数据接口，价格便宜、覆盖面全，但它的日线数据有两个毛病必须处理：一是停牌日通常不返回记录，行与行之间的日期不连续；二是部分历史数据没有完善的复权因子，需要自己根据除权除息公告补齐。

我的原始行情表设计成四个文件：基本信息表、日线行情表、复权因子表、交易日历表。日线行情的字段是：

date, code, open, high, low, close, volume, amount

复权因子表单独存，不直接在行情表里改价格。这样设计的好处是，计算时想用前复权还是后复权，都可以随时现算，不用把原始数据改坏了。交易日历表则是全市场统一的交易日索引，后面做宽表对齐的时候全靠它。

3.2 复权选择：算指标用后复权，展示用前复权

复权是技术指标计算里最容易被忽略、但影响最大的一个环节。股票分红除权那一天，价格会跳空，比如一只100块的股票10送10，除权后价格直接变50。如果你用不复权的数据算MA、BOLL、ATR，那一天及之后一段时间的指标全是扭曲的，金叉死叉会被硬生生造出来。

市场上一般有前复权、后复权两种口径。前复权以最新价格为基准，把历史价格往下调；后复权以最早上市日为基准，把分红累积到价格里。关键是：前复权的历史价格会随着最新价的变化一直漂移，今天拉出来的历史序列，和半年后拉出来的同一段历史，数值不一样。

这意味着扫描系统里如果存的是前复权数据，历史信号就无法稳定复现——今天算出来的"2023年5月出现过金叉"，半年后这个金叉可能就消失了。所以我定了一条铁律：指标计算一律用后复权数据，后复权序列是固定的，历史不漂移。展示和对比价格时才转成前复权，那是给人看的，不进计算管线。

3.3 停牌、新股、ST、一字板：一套清洗规则

清洗规则我写成了一张表，扫全市场之前先过一遍：

这里面最值得说的是一字板。一字涨停的那一天，开盘价、最高价、最低价、收盘价四个值完全相同，很多以最高最低价为基础构造的摆动类指标会退化，比如KDJ的RSV分母变成0，需要加保护。这个不是错误，是数据本身的特征，信号生成逻辑里必须知道当天存在这种情况，否则会选出根本买不进的票。

3.4 存储形态与内存估算

存储我选用了Parquet格式，按交易日期分区，每天一个文件。理由很简单：扫描是按日进行的，每天只需要追加最新一天的数据；而分析时要按股票取完整历史，Parquet的列式存储和压缩比能让文件小到原始CSV的三分之一左右。

计算时则反过来，把日线行情按股票组织成宽表。这个转换我认为是全系统最核心的内存策略：把"date × code × 字段"的长表，变成"date × code"的矩阵。一只股票2500个交易日，5000只股票，一个价格矩阵的规模是5000列 × 2500行，每个float64占8字节，大约100MB。开高低收再加上成交量，五六个矩阵也就500MB左右，现代机器完全吃得消。

内存不是问题之后，"全市场扫描"就从I/O密集型问题变成了纯计算问题，而且计算本身也变得极其简单——后面马上说到。

4. 三种计算路线实测：从逐股循环到宽表矩阵

4.1 路线一：逐股循环调指标库

最开始我用的是最直觉的写法：从股票列表里拿一只，读历史数据，调用指标库算出51个指标，存结果，再拿下一只。这几乎就是单票分析的直接放大版。

实话说，功能是能跑通的。但跑到5000只股票时问题全暴露了：

• 函数调用太密集。每只股票51次函数调用，5000只就是25.5万次，就算每次调用只要零点几毫秒，纯调用开销也在分钟级；
• 重复计算严重。每只股票独立算MA/EMA/TR，没有任何复用；
• 数据处理碎片化。每循环一次都要做一次NaN检查、边界处理，逻辑分散在循环体内，后期加指标越来越难改。

这个方案在我机器上实测，5000只股票 × 51个指标，跑完全程大约85秒，加上读数据和落盘，稳稳超过2分钟。不算灾难，但30分钟的目标虽然能完成，迭代空间太小——以后指标加到80个、股票再扩容，时间就失控了。

4.2 路线二：groupby 逐列滚动

第二次尝试是长表思维。把5000只股票的历史数据放在一个长表里，按股票代码groupby，然后在组内做滚动计算。这个思路理论上能减少循环次数，但实际体验更差：

groupby分组本身很快，但真正的坑在滚动窗口。pandas的rolling().apply()一旦传入自定义Python函数，性能直接掉一个数量级——因为每一行都要回调一次Python函数。5000只股票 × 2500个交易日 × 51个指标，哪怕只对其中几十个用自定义函数，时间也是灾难级。

这条路只适合用内置C实现的roll（比如rolling(n).mean()、rolling(n).std()）能覆盖的少数指标，稍微复杂一点就得自己写加速，不划算。

4.3 路线三：宽表矩阵化，也是最终采用的方案

宽表思路前面提过：把所有股票的价格序列对齐到统一的交易日历上，形成多个并列的矩阵，然后所有指标计算都变成对整张矩阵的操作。

比如算MA20，一行代码：

ma20 = close_matrix.rolling(20, axis=0).mean()

这里close_matrix的形状是(交易日, 股票数)，rolling沿着时间轴（axis=0）滑动，每一列是一只股票，pandas在底层用C语言实现这个滚动均值，一气呵成。再比如算EMA：

ema12 = close_matrix.ewm(span=12, adjust=False).mean()

5000列EMA同时算完，底层是C代码，速度非常可观。KDJ这种递归指标稍微麻烦一点，但卷积化处理也能做到矩阵级运算：先用滚动极值算出RSV矩阵，再对整个矩阵做两次递归平滑——pandas的ewm虽然不直接支持国内的SMA(X,N,1)递归，但这类递归本质上是IIR滤波器，用scipy.signal.lfilter一行搞定，性能照样是矩阵级的。

矩阵化的最大好处不只是快，而是代码量大幅减少。51个指标全部算完，核心代码不到300行，每个指标基本就是一行矩阵运算加必要的NaN处理。维护成本比逐股循环低了一个量级。

4.4 实测数据和并行化的取舍

同样在我笔记本上，5000只股票 × 2000个交易日 × 51个指标，三种路线的实测对比：

6秒是什么概念？加载数据5秒、计算6秒、结果落盘3秒，整个每日扫描流程在15秒内结束。加上清洗和自检，30分钟的目标余量非常充裕。

有人问我为什么不用多进程/多线程。我的实测是：宽表矩阵化后单核C代码已经把活干完了，再多分进程反而引入序列化成本和内存拷贝开销。真要并行，也是把计算切块后扔给几个进程各跑一部分矩阵，收益在数据规模还不到10000只股票的情况下并不明显。先把算法从"逐股循环"优化到"矩阵向量化"，再做并行，顺序不能反。

5. 扫描结果怎么存、怎么查、怎么变成信号

5.1 结果表结构：一票一行，当天快照

计算跑完只是开始。25.5万个指标值如果不设计好存储，后面查起来就是灾难。我用的结果表是"一票一行"的当天快照结构：

date, code, ma5, ma10, ma20, ma60, ema12, ema26, dif, dea, macd_hist, kdj_k, kdj_d, kdj_j, rsi6, rsi12, rsi24, boll_upper, boll_mid, boll_lower, atr14, obv, vr, mfi, ... (共51个指标列), listed_days, is_st, pct_chg, limit_up, limit_down

每天跑完，生成当天的快照，按日期分区存Parquet。查询时用嵌入式列式数据库直接按日期过滤，比如查"2024年5月20日全市场MA20金叉MA60的股票"，就是一个SQL：

SELECT code, ma20, ma60 FROM daily_snapshot WHERE date = '2024-05-20' AND ma20 > ma60 AND ma60 > ma20_pre

这种存储结构的优点是查询简单、语义清晰，缺点是每天多占一点磁盘。5000行 × 60列，一天也就几MB，存十年才几个GB，磁盘压力完全可接受。

5.2 截面百分位：把51个指标统一到同一起跑线

全市场扫描的另一个刚需是横向可比。同一只票的RSI是80，另一只票的RSI也是80，但一个处于长期高位，一个刚突破——只看原始值，你无法判断谁更极端。

我采取的做法是给每个指标再加一层"截面百分位"：每个交易日收盘后，把全市场5000只股票某个指标的数值排个序，算出它当日在全市场的百分位。这样一来，MACD柱、KDJ的J值、ATR这些量纲完全不同的指标，全部统一到0到100的百分位上，可以直接相加、加权、做共振筛选。

截面百分位的价值在于它把"绝对数值"变成了"相对状态"。比如BIAS乖离率，单看数值你不知道多大算大，但看百分位，95%就意味着这个乖离水平在全市场排前5%，是个明确的极端信号。后面所有信号评分，我基本都是基于百分位做的。

5.3 多指标共振与每日候选清单

有了指标快照和截面百分位，信号生成就变成了一组可配置的规则。我写的第一个共振策略长这样：

• 趋势过滤：收盘价 > MA20 > MA60，且MA20向上；
• 动量确认：MACD柱为正，DIF在DEA上方；
• 量能配合：当日成交量 > 5日均量的2倍；
• 摆动不极端：KDJ的J值百分位低于95，排除超买；
• 非一字板、非ST、上市满120天。

跑一遍全市场，候选通常剩三五十只，再按截面综合得分排序取前30，生成Excel和摘要。这个逻辑看起来简单，关键是整个链路上的每个环节——指标值、百分位、过滤条件——都来自同一份快照，可复现、可解释。

我还专门做了历史回放功能：给定任意历史日期，重算当天截面，输出当时的候选名单。这个功能在复盘信号质量时特别有用，能直接验证"如果当时按这个策略选股，结果怎么样"。

6. 和行情软件对不上？这些校验步骤救了我

6.1 指标对拍：选10只票、3个日期，逐项核对

系统第一次跑通的时候，我信心满满地把扫描结果拉出来看，结果随手抽查一只票的MACD，和行情软件上显示的数值对不上。仔细一查，柱状图差了正好一倍——国内软件的MACD柱是2×(DIF-DEA)，而我按国际惯例输出的是DIF-DEA。

这就是之前说的"方言"问题，在真实对拍里立刻现了形。所以我把"对拍"做成了标准流程：随机挑10只风格不同的股票——大盘权重、中小盘、次新、高送转过的——取3个历史日期，把MACD、KDJ、RSI、BOLL四个最常用的指标逐项和行情软件比对，允许的误差只到0.001。

这项工作看起来笨，但价值极大。指标计算系统的质量核心不是代码写得漂亮，而是和公认口径一致。每修完一个差异，我都会把对应的检查项固化到自动化脚本里，以后每次改指标逻辑都必须重新跑一遍对拍。

6.2 未来函数与信号漂移检查

技术指标计算里最隐蔽的问题是未来函数——某个时点的指标值意外地使用了未来数据。最典型的来源有两个：一个是复权因子处理不当，某天的价格里掺入了后面除权除息日才确定的信息；另一个是滚动窗口使用不当，比如本应截至当日的窗口不小心包含了次日数据。

我的检查方法很简单：截断重算。取历史数据的某一天T，用"截至T日"的数据重新算一遍T日的指标值，再和"用完整历史算出来的T日指标值"对比。如果一致，说明没有未来函数；如果不一致，说明窗口里有"来自未来的信息"。

这个测试对后复权数据尤其重要。因为后复权价格本身依赖整个生命周期内的除权事件，如果复权因子里用了未来的除权信息，那么任何历史时点的指标在重算时都可能漂移。我最后是把复权因子的计算严格限制成"截至当日已知的除权公告"，才算彻底解决这个问题。

6.3 NaN传染与边界数据：信号生成的隐形杀手

再说一个特别容易被忽视的坑：NaN是会传染的。rolling窗口宽度是20，那只股票哪天突然缺一行数据，后面的指标可能连续20天都是NaN；新股上市满60天之前，MA60永远算不出来；用rolling().mean()对含NaN的窗口计算，结果一律是NaN，而且这个NaN会顺着指标公式一层层扩散到MACD、KDJ的上层指标。

我的办法是指标函数全部显式处理NaN，并且把"上市天数不足"这种结构性缺失和"数据损坏缺失"区分开。前者是正常的，信号过滤时直接跳过；后者必须报警，因为某天成交量数据坏了但没人发现，后续所有量能指标都会带病上线。

所以每天扫描流程的开头有一个数据自检步骤：检查全市场当日行数是否接近预期、关键字段缺失率是否超过阈值、有没有异常的价格跳变。任何一个不通过，整个扫描流程就停止并报警，绝不拿着脏数据往下跑。这个"宁可不跑，不可错跑"的原则，事后看救过我很多次。

6.4 边界情况的处理经验清单

几个容易反复踩的边界情况，我整理成清单放在代码注释里：

• 一字板当天开=高=低=收，KDJ/RSV遇到分母0要保护；
• 停牌复牌当天，前一交易日和后一交易日之间没有连续性，ATR会被跳空放大——这是真实信息，不是错误；
• 涨跌停滤波：扫描出的信号如果次日是涨停开盘，实际成交可能进不去，别把信号当成"可成交"的信号；
• 除权日前后，后复权价格序列平滑但未复权涨跌幅会突变，pct_chg列必须用复权价计算。

这些都是"算出来容易，算对了难"的地方。全市场扫描输错一个数值，可能只是一个小数点的事，但落到筛选结果上，就是一批错误的候选股票。

7. 落地后的几个运维心得

系统稳定跑了几个月后，我总结了几条实际运维中的体会，可能比上面的技术细节更值钱。

第一，把系统做成幂等的。同样的输入数据，跑多少次输出都必须完全一致。为此我做了两件事：所有计算都基于同一份快照数据，绝不在计算过程中去实时拉取外部接口；所有随机因素（如果存在）都必须有固定种子。这样一旦结果有疑问，随时可以重跑复现。

第二，指标配置和代码解耦。51个指标的计算逻辑虽然手写成矩阵运算，但它们之间的依赖关系、参数配置（比如MA的周期、BOLL的倍数）全部外置到一个独立的配置文件里。跑批脚本不感知具体指标，只是按依赖树调度。后来我把指标从51个扩展到70多个，核心代码一行没改，只新增了配置和对应的计算函数。

第三，全量重算比增量更新省心。很多人觉得每天只更新最新一天的数据，应该做增量计算。但实际上在宽表矩阵方案里，全量重算一次也就6秒，增量更新反而要处理窗口衔接、NaN补位这些复杂逻辑，出错概率更高。我最后选择了每天全量重算，简单、干净、可信。

最后分享一个小技巧：我给每只候选股生成一份"指标快照"文件，包含它当天51个指标的原始值、截面百分位，以及过去20天的指标序列。这样做人工复核时不用再打开行情软件翻来翻去，所有判断依据都在一张表里，签字确认也方便。这个习惯让筛选结果的争议率大幅下降，因为你拿出来的是可追溯的完整证据链，不是一句话结论。

这套系统从设计到稳定运行，最深的体会是：全市场技术扫描的难点从来不在"算",而在"把算这件事做得可靠、可复现、可解释"。指标对拍、未来函数检查、数据自检这些环节，每一环都是在为可靠性买单。如果把系统比作一台机器，指标计算只是它的引擎，而数据清洗、依赖编排、结果追溯才是让这台机器每天能按时出工的保障体系。