本文系 AI 生成，仅供参考，不保证准确性，实战中务必将结果与专业软件中的数据进行对比。
在量化交易和股票数据分析中，“复权”是一个绕不开的核心概念。很多新手在搭建自己的数据库或编写策略时，常常因为复权处理不当，导致回测结果失真、技术指标错位，甚至引发系统性的计算灾难。
本文将从底层逻辑出发，用大白话为你讲透复权的本质，并提供一套成熟、高效的数据库与指标设计方案，帮你完美避开各种“坑”。
一、股票中的“复权”是什么意思？
简单来说，复权是为了消除股票因分红、送股、配股等除权除息事件造成的K线价格“断崖式”缺口。
二、如何计算复权因子？
复权因子本质上就是除权前后的价格比例，但不同数据源的定义方向恰好相反：
• BaoStock 算法：复权因子 = 除权后价格 ÷ 除权前价格（结果小于 1，如 10 ÷ 20 = 0.5）。
• 掘金量化算法：复权因子 = 除权前价格 ÷ 除权后价格（结果大于 1，如 20 ÷ 10 = 2）。
无论哪种定义，其核心作用都是作为一个乘数，用于在不同历史价格之间进行等比换算。
三、将股票历史价格保存到数据库中时，建议使用真实价格还是复权价格？
四、以MA5为例，如何计算和保存指标价格？
• 计算与存储：永远使用“真实价格”来计算 MA5，并将结果存入数据库。这样历史指标是客观事实，无需因复权而重算。
• 展示与应用：在看盘或跑策略时，将数据库中的真实 MA5 乘以“当前的复权因子”，即可动态映射出完美的复权 MA5。
举个例子：某 6 天的真实价格是 20，21，22，23，24，12，其中最后一天进行了除权，且假设这天没涨没跌，掘金因子是24/12=2，这样的话，倒数据第 2 天的 MA5 是 (20+21+22+23+24)/5=22，最后一天的 MA5 是 (21/2+22/2+23/2+24/2+12)/5=11.4，所以数据库中这两天的 MA5 值分别是 22 和 11.4 。复权因子同样适用于 MA5 值，即从最后一天看，其前一天的前复权 MA5 值是 22/2=11。
五、如何解决复权因子与四舍五入叠加产生的偏差问题？
核心原则是 “真实价格负责算钱，复权价格负责算趋势” （实盘中）：
• 交易与风控层：涉及真实盈亏、涨跌停价计算、下单挂单等，必须使用精确到两位小数的“真实价格”。
• 研究与回测层：涉及画K线图、计算 MA 等趋势指标时，才使用复权价格。此时允许存在极微小的尾数误差（如 1 分钱），因为技术指标看的是宏观趋势，微小偏差对信号毫无影响。
举个例子：真实价格 12.34（2位小数），复权因子 0.965678，前复权价格 12.34 × 0.965678 = 11.91646652（8 位小数）
如果你用这个 11.91646652 去算涨停价：11.91646652 × 1.1 = 13.108113172，四舍五入变成 13.11。
但是，真实的涨停价是 13.57，它的前复权价应该是：13.57 × 0.965678 = 13.10429046，四舍五入变成 13.10。
六、前复权与后复权在实际应用中该如何选择？
• 前复权：以当前最新价格为基准，向下平移历史价格。优点是最新价格与真实交易价格一致，适合看近期K线走势、分析短期技术形态。
• 后复权：以历史最早价格为基准，向上放大最新价格。优点是能真实反映上市以来的累计涨幅，适合计算长期累计收益率、评估长线投资价值。
附：复权因子计算实战案例（小白秒懂版）
T 日公司宣布“10 送 10”，股价直接“腰斩”变成 10元。假设 T 日当天市场不涨不跌，实际收盘价依然是 10元。
1. 复权因子怎么算？
• BaoStock算法：10 ÷ 20 = 0.5
• 掘金量化算法：20 ÷ 10 = 2
2. 前复权怎么算？
前复权的核心是：T 日的 10元 保持不变，把 T-1 日的价格乘以 BaoStock 的因子（0.5）。
• T-1 日前复权价 = 20 × 0.5 = 10元
• T 日前复权价 = 10元（因为T日是基准日，保持不变）最终结果：T-1 日是 10元，T 日是 10元。K 线图完美连续，没有缺口。
3. 后复权怎么算？
后复权的核心是：T-1 日的 20元 保持不变，把 T 日的价格乘以掘金的因子（2）。
• T-1 日后复权价 = 20元
• T 日后复权价 = 10 × 2 = 20元最终结果：T-1 日是 20元，T 日是 20元。K 线图同样连续，反映了你“虽然股价没涨，但手里股票翻倍了，总资产没变”的真实情况。
4. 技术指标（以 MA2 为例）怎么算？
• 数据库里存什么？ 存真实价格算出来的指标。
◦ T-1 日前复权价格 = 20 × 0.5 = 10
◦ T 日前复权价格 = 10（前复权以当日为基准，保持真实价格不变）
◦ T 日真实 MA2 = (10 + 10) ÷ 2 = 10
复权只是数学游戏。真实价格负责算钱，复权价格负责看趋势；数据库里只存真实指标，看盘时再乘因子映射。
(AI 生成)
报道称 NGINX 被曝一组高危漏洞，已潜伏约 18 年，威胁全球约三分之一的网络服务器。
本次曝光的漏洞如下：
CVE-2026-42945 - (9.2 Critical)
CVE-2026-42946 - (8.3 High)
CVE-2026-40701 - (6.3 Medium)
CVE-2026-42934 - (6.3 Medium)
攻击者无需登录认证，只需发送一条特制 HTTP 请求，就能让 NGINX 工作进程崩溃；在合适条件下，还可能拿到服务器远程代码执行权限。
修复方案一
NGINX 升级到 1.31.0 或 1.30.1
修复方案二
若你使用的是 OpenResty 或宝塔面板，没有更新的 nginx 版本选择，那么手动修复此漏洞。
将 rewrite 规则中的未命名正则捕获改成命名捕获。
示例：
原来的写法：
rewrite ^(.*)$ /index.php?s=$1 last;修改为：
rewrite ^(?<a>.*)$ /index.php?s=$a last;参考文献：
如果你不会激活 Windows，本文可能不适用。
C盘满了如何清理？特别是 C:\Windows\WinSxS 占用大量磁盘空间，删又不敢删。
推荐一个比较完美又彻底有效的办法：
设置-系统-恢复-使用 Windows 更新修复问题。
或下载与原系统版本一致的 Windows 原版安装镜像，双击运行，选择保留个人文件和应用，等待约半个小时。
完成后，原来安装的应用程序和设置会保留，无用的系统文件会移至 C:\Windows.old。
若新系统运行没有问题，则可删除该目录（设置-系统-存储-清理建议），释放磁盘空间；若有问题，可还原到原系统（设置-系统-恢复）。
在MySQL中，没有单条SQL语句能直接优化和修复所有表。不过，有以下两种常用方法可以实现这个需求：
1. 使用MySQL命令行工具:
mysqlcheck -u root -p --auto-repair --optimize --all-databases这条命令会提示输入密码，然后自动修复并优化所有数据库中的所有表。
2. 如果确实需要在MySQL客户端内执行，可以生成批处理语句：
SELECT CONCAT('OPTIMIZE TABLE ', table_schema, '.', table_name, '; REPAIR TABLE ', table_schema, '.', table_name, ';')
FROM information_schema.tables
WHERE table_schema NOT IN ('information_schema','mysql','performance_schema','sys');执行此查询后，复制结果中的所有语句再执行。
注意：执行表优化和修复操作需要相应权限，且在高负载生产环境中应谨慎操作，最好在低峰期进行。
解析域名（非网站域名）、修改实例名称、主机名
设置阿里云（重要）
远程连接进入 ECS（若解析未生效可以先用 IP）（若新服默认使用 22 端口，可在阿里云控制台登录系统，或先在安全组临时放行 22 端口）
修复系统漏洞
将磁盘挂载到目录（fdisk、df 命令参考：https://xoyozo.net/Blog/Details/SSH）
安装宝塔面板（本文以宝塔面板方案为例，选择任何你喜欢的环境部署方案都行）。可以在阿里云控制台ECS实例页安装扩展程序
临时放行宝塔面板端口，进入宝塔面板（http方式），或用命令更改宝塔面板端口
配置面板 SSH、添加新的安全端口、面板设置
更改 SSH 默认端口（参：https://xoyozo.net/Blog/Details/change-default-port）
安装 nginx、PHP 等
配置 PHP 扩展（Redis、sqlsrv（注意选择兼容的版本）、memcached 及端口）
创建网站，配置网站（路径、伪静态等）
迁移网站文件（参：https://xoyozo.net/Blog/Details/SSH）
仔细对比新旧网站的配置文件（特别是 .php 的访问权限，参：https://xoyozo.net/Blog/Details/nginx-location-if）
设置写入目录（使用 rsync 同步的文件会同步用户和权限）
解析域名（先改 hosts 测试网站功能）
更改内网其它 ECS 上的 hosts
关闭原 ECS（能马上发现问题，不然等运行一段时间才发现问题就麻烦点）
设置 FTP
迁移“计划任务”
所有网站和软件的配置文件都要使用 WinMerge 进行对比
移除“宝塔面板-安全”和“阿里云-ECS-安全组”中不用的端口
再次检查阿里云设置
私网中若有 ECS 的 hosts 中域名直接绑定到私网 IP 的，做相应更改
其它：ERP 添加到期提醒、WAF 增加该 ECS、备份工具增加该 ECS
更多文章：
本文过程较为复杂，且部分内容已无法实现，建议点击这里查阅最新的操作方法！
前言：本文操作需要你具备浏览器安装和使用扩展插件的能力、以及简单的使用命令行的能力。
第一步：下载视频
首先我使用 Edge 浏览器（Chrome 操作类似，不过安装扩展需要科学上网）。
2023 年初的时候，用 FetchV 这个扩展是非常方便的，它会自动嗅到网页中的视频，即使没有嗅到也可以用录制的方式来保存。
但到了过了一两个月发现 FetchV（及其马甲）经常打不开，或者无法嗅到视频流，更别提录制了。
所以我找到了另一款专业视频下载神器：
当然它的马甲们用法也是大同小异，主界面是这样的：
开启捕获，同意下载多个文件，然后播放视频，耐心等待。
心急的朋友可以用修改播放速度的扩展（如 视频加速减速控制），例如用 16 倍速，那么一个 16 分钟的视频用 1 分钟就播放完成了。（或者在 F12 的控制台中使用 JS 代码加速：document.querySelector('video').playbackRate = 16; ）
等小浮框提示“捕获完成 点击下载”的时候就可以保存到磁盘上了。
第二步：音频修复
下载后它会有两个 .mp4 文件保存到电脑上，其中较大的是视频部分，较小的是音频部分。
但是有个小问题是，这个音频文件用 Windows 自带播放器播放正常，用 potplayer 等第三方播放器或者一些视频编辑软件播放就会有问题。
我在 Microsoft Store 中找了一款叫 Movie Maker - Video Editor 的应用，
在这个软件中添加刚才的只有音轨的视频文件会提示转码，转码后的 .mp4 文件音轨就正常了。
具体步骤是依次点击“Create New Project”，“Add clip”，“Photo/Video”，选择文件后“Transcode”，保存以后默认会在文件名后加上“ (Transcoded).mp4”。
第三步：音视频合成
接下来是合成视频和音频，将视频文件命名为 v.mp4，音频文件命名为 a.mp4。
在 FFmpeg 官网下载 Windows 版，然后使用这个命令从音频文件中提取音轨：
ffmpeg -i a.mp4 -vn -acodec copy a.aac再用这个命令将 v.mp4 的视频和 a.aac 的音频合成一个新的文件
ffmpeg -i v.mp4 -i a.aac -c:v copy -c:a copy -map 0:v:0 -map 1:a:0 output.mp4相比于其它的视频转换工具，ffmpeg 直接提取合并的速度是极快的。
Tips：
小鹅通中学习过的课程再次打开会从上次关闭的地方开始播放，这会导致捕获不全，可以将进度条手动拖到末尾，这样它会停止播放，再次刷新就会从头开始播放。
浮框中“点击下载”可能没反应，估计是在合成文件，过几秒钟多点几下，不会重复下载。
如果要下载的视频比较长或者比较多，可以像我一样在虚拟机里进行，把视频播放器的音量开到最大，把操作系统的声音关闭。
下载 sqlmap：https://github.com/sqlmapproject/sqlmap
下载 python：https://www.python.org/downloads/
以 windows 版为例：
安装 python；
解压缩 sqlmap；
“在终端中打开 / 在命令行中打开” sqlmap.py 文件所在目录；
执行命令
python sqlmap.py -u "网址" --data="POST数据" --tables需要注意的是，sqlmap 会记录探测过的网址的结果信息，修复网站漏洞后要再次检测是否安全时，应删除缓存文件，位置在：
C:\Users\用户\AppData\Local\sqlmap\output\
错误 TS5055 无法写入文件“***.js”，因为它会覆盖输入文件。
添加 tsconfig.json 文件有助于组织包含 TypeScript 和 JavaScript 文件的项目。有关详细信息，请访问 https://aka.ms/tsconfig。
检查“输出”窗口，找到“error”的行，并修复该错误。
一种可能的情况是，使用了 vue3 的 computed 计算属性。原因未知，尝试又定义了一个变量并使用 watch 侦听原变量来给它赋值，同样报错。
论坛出现动态页面打开或刷新非常慢（超过半分钟），甚至打不开，该页无法显示，502 Bad Gateway 等情况，TTFB 计时需要好几秒。
切换 nginx 版本、php 版本 等均无效果，甚至购买新的 ECS 重新搭建环境也是效果甚微。
最终在阿里云 RDS 管理中，手动主备库切换，问题得以解决。
因此大概率是原主库有问题（有损坏的表需要修复或锁等情况）。
查询故障时间段的慢 SQL，发现某表的锁等待时间特别长，不知道是不是这个表的原因导致的。
次日，提交工单得到回复是原主库（现备库）会自动修复，经再次主备库切换测试得到了肯定的结果。
再次日，又遇到同样的打开慢的情况，这次直接找到慢 SQL 中锁等待时间较长的表，优化（OPTIMIZE TABLE）（虽然是 InnoDB），立刻解决了问题。