简介这是面向 Delphi 与 CBuilder 开发者的 MyDAC v5.10 完整源文件包用于在 Delphi 7 至 2007 环境中高效连接 MySQL 数据库。组件原生直连 MySQL不依赖第三方中间件支持事务、存储过程、批处理与异步操作适合需要深度定制数据库访问层或学习组件内部实现的中高级开发者。包内共 1403 个文件压缩后仅 1.39MB。核心以 360 个 Pascal 源文件.pas、146 个 Delphi 包.dpk和 107 个窗体定义.dfm为主另有 CBuilder 工程文件、构建脚本、帮助文档及许可协议便于按需查看、编译和二次修改。资源附带使用说明和常见问题解答可帮助理解源码结构与安装步骤已有 166 人查看学习适合希望在原版组件基础上增加定制功能、排查连接问题或移植到具体项目的开发者。1. MyDAC v5.10 源文件一间还亮着灯的 Delphi 老铺子如果有人把一份 MyDAC v5.10 源文件发到你手里多半不是闲着没事。可能是接手十年前的进销存系统也可能是公司规定不能用 ODBC 裸连 MySQL还有可能是手头正好有一个跑在 Delphi 7 上的老服务要改表结构又不敢动运行环境。MyDACMySQL Data Access Components是 Delphi/CBuilder 环境里直连 MySQL 的老牌控件v5.10 是它相当典型的源码版形态拿到手的是 .dpk、.pas、.dcr 这一堆组件源文件而不是装完就能用的 .bpl。这篇文章想讲清楚我从拿到这份源文件到真正能用上它的全过程编译路径、连接配置、改动点以及几个足够让人卡一整个下午的坑。适合读它的人是那些必须在老编译器版本上维护 MySQL 应用、又不想被 ODBC 驱动折腾的从业者。2. 把源文件编译进 IDE先分清两个包再动手2.1 先确认源文件形态.dpk、.pas、.dcr 缺一不可拿到源文件后第一件事不是双击 .dpk而是先看目录结构。MyDAC 这种带源码发行的控件文件夹里通常会有 Source、Packages、Demo 三类东西Source 下是组件实现的 .pas 和 .incPackages 下是按不同 Delphi 版本组织的 .dpk 包定义Demos 里有现成的连接示例。v5.10 这个年代的产品还沿用一个老规矩.dcr 文件负责组件在面板上的图标如果把 .dcr 落下编译能过、上班后也能连库但组件面板上那一排小图标会全部变成默认的方块。另一个容易忽略的点是版本对应关系。MyDAC 的包是按编译器版本拆分的同一个 v5.10Delphi 2007 和 Delphi XE2 用的包源文件不一样拿错包会直接编译失败而且报错信息不太直观经常是某一行 .pas 语法不认识。现实里最常用的组合是 Delphi 2007 接这份源文件因为大量老进销存工程就是那个时期写的。开 .dpk 之前先确认你 IDE 的编译器版本再确认 Packages 目录下对应版本的子目录这一步值得花三分钟省得后面反复清理。2.2 用 IDE 安装把源文件路径放进 Library 再装包选择源码版而不是官方二进制版理由其实很朴素能改行为。老组件连新数据库出问题时你至少能打开 .pas 看它到底发的什么握手报文而不是对着黑匣子猜。代价是自己负责编译和分发这也是下面整套流程存在的原因。安装路径我习惯分三步走。第一步打开 IDE 的 Tools Options Library把源文件的 Source 目录加进 Library path不加这一步直接开包后面几秒就会跳一串找不到单元的报错。第二步在 Project Manager 里打开 Packages 目录下对应编译器版本的运行时 .dpk右键 Compile只看不装。第三步打开同目录下带 Design 字样的设计期包右键 Install。两步不能反过来运行时包装进去的话IDE 启动会反复提示包已经存在然后拖慢整个加载过程。安装完成后验证产物是否落盘。不同 IDE 版本的 BPL 输出目录不一样常见的是 IDE 安装目录下的 bin 或系统 System32直接按文件搜也行# 在 Windows 下检查 MyDAC 的 bpl 是否安装成功 # 路径换成你当前 IDE 的 BPL 输出目录下例以 RAD Studio 2007 为例 dir C:\Program Files\CodeGear\RAD Studio\5.0\bin\MyDAC*.bpl # 如果 IDE 是 64 位安装版还要看 SysWOW64 下的同名文件 dir C:\Windows\SysWOW64\MyDAC*.bpl这个检查看起来多余但很值得做。我曾经装完包后组件面板一切正常过几天换了一台机器重新拉代码打开工程却提示找不到包原因就是当时 bpl 的输出目录没有跟着工程一起进版本库。IDE 自动把编译产物写到了它自己的目录而新机器根本没编译过。源码版控件一定要记住一条bpl 是编译产物不是源码的一部分谁的新机器都要走一遍编译流程。2.3 用命令行出 bpl/dcp给 CI 和离线编译留一条路老项目经常要上自动化编译每天夜里定时拉代码、编译、出版本。这时候靠人打开 IDE 再点 Install 是不现实的得用 Delphi 自带的命令行编译器 dcc32。MyDAC 这种源码包在命令行下编译并不复杂只是要把源文件路径、输出路径和包文件路径一次性交代清楚。# 用 dcc32 命令行编译 MyDAC 运行时包 # 首次编译建议用 -B 全量构建之后日常增量用 -M dcc32.exe -B ^ -UD:\lib\MyDAC\Source ^ -ND:\lib\MyDAC\Output ^ -ED:\lib\MyDAC\Output ^ D:\lib\MyDAC\Packages\MyDAC_R.dpk这里 -U 指定源文件搜索路径指向 Source 目录-N 指定 .dcp 输出目录编译期链接要用它-E 指定 .bpl 输出目录运行期加载要靠它。包文件路径换成你手里的实际 .dpk 名。命令行编译的好处是不挑 IDE 环境在只装了命令行工具链的编译机上也能跑执行之前记得把 dcc32.exe 所在目录加进 PATH否则系统会提示找不到命令。命令行编译常见的一个坑是路径里的空格。IDE 里能自动处理带空格的路径命令行却经常在空格处断开老版本的 dcc32 尤其敏感。解决方法是路径整体加引号或者干脆把源文件解压到一个不带空格的纯英文目录比如 D:\lib\MyDAC。这个目录习惯我保持了很多年连带那个 MySQL 连接测试工程也放在 D:\dbtest 下宁肯路径丑一点不想跟 Shell 转义较劲。2.4 编译产物怎么摆别把源文件留在系统目录源码版编译完成后开发机和生产机的文件职责要分开这是我的习惯。开发机上保留完整源文件、.dcp 和 .bplIDE 打开工程时通过 Library path 找到 .dcp生产机上只放程序运行时必需的 .bpl 和可执行文件.pas 和 .dcp 都不带过去。这样出问题时能快速定位是不是运行时包版本和编译时不一致也能避免源文件被人顺手改掉但毫无记录。文件开发机生产机作用.pas / .inc保留不带源码改行为和排错用.dcp保留不带编译期链接依赖.bpl保留按需携带运行期加载和 exe 同级目录.dcr保留不带IDE 设计期图标资源之所以把这一点单独拿出来说是因为我见过同事把整个 Source 目录拷到 System32 下的做法当时编译是过了但三个月后没人搞得清哪个目录里的 .pas 才是真身。源码版控件的优势在于可控劣势也在于此你要自己维持秩序。给源码包建一个 git 仓库每改一个文件都留下记录这是我吃过亏以后养成的习惯。3. 连接与增删改查TMyConnection 的最小可用配置3.1 TMyConnection 连接参数Server、Port、Database、Charset组件装好以后第一个要拖到窗体上的是 TMyConnection。它好比整条数据库链路的入口几乎所有后续组件都要挂在它下面。用 TMyConnection 而不是旧项目的 TDatabase 加 ODBC核心理由是 MyDAC 直接走 MySQL 客户端协议不依赖系统 ODBC 驱动字段类型映射、存储过程和字符集处理都比 ODBC 那条路干净。procedure TfrmMain.FormCreate(Sender: TObject); begin MyConnection.LoginPrompt : False; MyConnection.Server : 127.0.0.1; // 远程库就写远程主机名或 IP MyConnection.Port : 3306; // MySQL 默认端口 MyConnection.Username : app_user; MyConnection.Password : app_pass; // 正式环境别硬编码第 4 章细说 MyConnection.Database : erp; MyConnection.CharSet : utf8; // 老组件对 utf8mb4 支持有限见 5.4 MyConnection.Connect; // 显式连接便于判断失败 end;这一段里最常见的误用是漏掉 LoginPrompt : False结果程序一启动就弹数据库登录框输入框还是那个老掉牙的默认样式用户看不懂也填不对。另一个是漏掉 Database连接成功后默认库不是业务库后面每条 SQL 都要带库名前缀改起来麻烦。Server 推荐直接写 127.0.0.1 而不是 localhost因为老组件在某些机器上会把 localhost 解析到 socket 连接去绕了远路还容易触发权限问题。连接参数里值得对照确认的是下面这组我整理成表方便复制到工程文档里参数常见值说明Server127.0.0.1推荐写 IP少写主机名Port3306改过端口就填实际值Username / Password应用账号不要用 root 跑业务Databaseerp默认库避免每次带库名前缀LoginPromptFalse程序启动不弹登录框CharSetutf8和库表字符集保持一致PoolingFalse老项目按需开启见 3.43.2 TMyQuery 的最小 CRUD从连库到增删改查TMyConnection 只负责建立和维护连接真正干活的通常是 TMyQuery。它同时承载查询和写操作区别只在调用方式Open 返回结果集ExecSQL 只执行不返回。这个区别是新手翻车重灾区SELECT 用 ExecSQL 执行后不是报错而是看起来没反应实际上结果集根本没被读出来。// 查询TMyQuery 绑定 DBGridOpen 后数据集可用 MyQuery.SQL.Text : SELECT * FROM orders WHERE status :st ORDER BY id DESC; MyQuery.ParamByName(st).AsString : NEW; MyQuery.Open; // 写操作UPDATE / INSERT / DELETE 一律走 ExecSQL MyQuery.SQL.Text : UPDATE orders SET fee fee 5 WHERE id :id; MyQuery.ParamByName(id).AsInteger : 1001; MyQuery.ExecSQL; // 批量执行TMyScript 一次跑多条语句语句之间用分号分隔 MyScript.SQL.Text : INSERT INTO logs(msg) VALUES(up); INSERT INTO logs(msg) VALUES(down);; MyScript.Execute;参数化是这条代码块里最该养成习惯的地方。字符串拼 SQL 在老项目里遍地都是但 MySQL 的 SQL 语法里单引号、转义符一多拼接逻辑马上变成一场灾难。用 ParamByName 传参除了防注入更重要的是让组件自己处理类型转换日期和时间字段尤其省心。如果遇到参数名带中文或者特殊符号导致参数识别失败改用 ? 占位符传参是 MyDAC 支持的备选方案。TMyScript 适合初始化数据、跑批量脚本这类场景但它默认不参与外层事务如果要保证多条语句的原子性得配合事务一起用见下一节。3.3 参数化查询与存储过程别再用字符串拼 SQL老系统维护者最头疼的往往是存储过程。当年写存储过程的人未必留下了文档现在要改业务逻辑只能先把这个过程调用通。MyDAC 里调用存储过程有专门的 TMyStoredProc 组件参数方向要分清楚输入参数和输出参数混在一起时必须先 Clear 再重新创建参数列表否则上一次调用的残留参数会串台。// 调用存储过程sp_recalc_stock 带一个输入参数和一个输出参数 MyStoredProc.StoredProcName : sp_recalc_stock; MyStoredProc.Params.Clear; MyStoredProc.Params.CreateParam(ftInteger, in_warehouse, ptInput).AsInteger : 3; MyStoredProc.Params.CreateParam(ftInteger, out_changed, ptOutput).AsInteger : 0; MyStoredProc.ExecProc; ShowMessage(IntToStr(MyStoredProc.Params.ParamByName(out_changed).AsInteger)); // 事务多步写操作必须显式控制提交时机 MyConnection.StartTransaction; try // 这里执行多条 UPDATE / INSERT MyConnection.Commit; except MyConnection.Rollback; raise; end;存储过程调用有一个隐蔽问题当存储过程本身有 SELECT 结果集时TMyStoredProc 的返回值处理和 TMyQuery 不同结果集需要额外遍历否则老版本组件会提示数据集未打开。如果遇到这个过程我的习惯是把存储过程拆成两部分看前面是计算逻辑后面是结果返回调用代码里分开处理。事务这块要特别提醒MyDAC 默认 AutoCommit 为真意味着每条 SQL 执行完就立即提交。显式开事务后要确认连接对象的 AutoCommit 已被关闭否则 StartTransaction 形同虚设。我在代码里习惯用 try..except 包裹事务体rollback 之后重新 raise把异常抛回给上层界面避免事务失败但界面毫无感知。3.4 连接池与 SSLv5.10 的 Pooling 连法老服务连 MySQL 最不起眼但影响最大的一个参数是连接池。没有连接池时每个线程每次操作都独立 Connect 和 DisconnectTCP 握手加 MySQL 认证一次要大几十毫秒高并发下连接数还会把 MySQL 的 max_connections 打满。MyDAC v5.10 的连接池是进程内的硬要点说就是组件把认证过的连接缓存起来复用而不是重新走一遍完整握手。// 连接池开启在 TMyConnection 的 Options 里统一配置 MyConnection.Options.Pooling : True; MyConnection.Options.PoolingTimeout : 60; // 连接空闲 60 秒后关闭 MyConnection.Options.PoolingMaxSize : 8; // 池内最多 8 条连接PoolingTimeout 设太短会让连接频繁重建池子失去意义设太长会把 MySQL 端已关闭的空闲连接留在池里下一次取出来时才报连接失效。我一般先设 60 秒观察一轮如果日志里频繁出现 socket 断开再适当调长到 120 秒。PoolingMaxSize 则要和 MySQL 服务端的 max_connections 联动应用多实例部署时单实例池大小乘实例数必须小于服务端上限否则照样爆连接。SSL 这个话题在 v5.10 上比较尴尬。那个年代的 SSL 配置和现在的 MySQL 8 默认认证插件并不兼容强行开 SSL 反而容易认证失败。稳妥方案是优先走内网通道靠防火墙和 MySQL 账号权限控制访问真要跨公网连远程库我一般先用工具验证 MySQL 服务端 SSL 证书链是否完整再决定组件里要不要开 SSLOptions。老组件在 TLS 协议版本上落后这条链路是最容易卡住的地方详细排查放第 5 章里讲。4. 从源文件改到私有分发四个你一定用得到的改动点4.1 改默认字符集把组件默认 Charset 从 latin1 换成 utf8老版本 MyDAC 的 TMyConnection 默认字符集经常是空值或 latin1每个新拖到窗体上的连接都得手动写一遍 CharSet写漏一个就乱码一个窗体。源码版的用途在这里体现出来了直接找到 TMyConnection 构造函数里的默认赋值把字符集改成 utf8重新编译运行时包全项目所有连接一次到位。// 在 TMyConnection.pas 构造函数中找到默认值赋值区 constructor TMyConnection.Create(AOwner: TComponent); begin inherited Create(AOwner); FCharset : utf8; // 把默认值从 latin1 改为 utf8 FAutoCommit : True; end;改完默认值之后记得要做两件事第一把改动记录到版本库最好是写成注释写在代码旁边说明为什么要改避免下一个人以为是笔误又改回去第二重新编译全部依赖这个单元的包不只编译运行时包设计期包也要重编否则 IDE 里预览组件属性时看到的还是旧默认值。这个改动虽然小但它是源码版控件的典型好处也是我向同事推荐源码版的第一理由。4.2 连接信息不写死在窗体用 OnBeforeConnect 动态给老工程的连接配置大多散落在各个窗体的 FormCreate 里换一次数据库密码要全局搜索替换还容易漏掉一两个隐藏窗体。源码版配合事件机制能把连接信息收拢到一个地方。TMyConnection 提供了 BeforeConnect 事件在真正发起连接之前触发在这里动态赋值即可。// 统一在 BeforeConnect 里根据配置文件设置连接参数 procedure TfrmMain.MyConnectionBeforeConnect(Sender: TObject); begin MyConnection.Server : LoadConfig(db_host, 127.0.0.1); MyConnection.Username : LoadConfig(db_user, app); MyConnection.Password : DecodeSecret(LoadConfig(db_pass, )); end;LoadConfig 和 DecodeSecret 是工程里已有的两个函数前者读 ini 或环境变量后者对密码做简单解密。这样做的直接收益是密码不再以明文出现在代码和窗体文件里换库换密码时只要改配置文件程序重新连接即可。这比在代码里到处写 ConnectionString 稳妥得多也方便测试环境切库——测试库和正式库唯一的差别就是配置文件里的几行值。这里要提醒一个细节BeforeConnect 里赋值的动作发生在每次连接之前而不是只在创建时。这意味着断线重连也会走这个事件密码被改过之后不必重启程序重连一次就能生效。如果配置读取失败记得在事件里给默认值并往日志里记一条免得程序连不上时无从查起。4.3 打开调试级 SQL 日志看组件到底给 MySQL 发了什么排查问题时最怕的是只知道一个现象——界面上报错但不知道组件发给 MySQL 的原始语句是什么。MyDAC 提供了日志和 Trace 一类的机制能把组件实际执行的 SQL 和返回结果的行数记录下来。v5.10 这个版本不同小版本之间属性名略有差异常见做法是通过 Options.Trace 或专门的日志属性打开如果找不到 Trace就用 TMyQuery 的 OnExecute 事件自己记录 SQL.Text。// 打开 Trace 日志SQL 连同执行信息写入文件 MyConnection.Options.Trace : True; MyConnection.Options.TraceFile : C:\logs\mydac_trace.log; // 如果当前小版本没有 Trace 属性退而求其次挂事件记录 procedure TfrmMain.MyQueryAfterExecute(DataSet: TDataSet); begin LogToFile(MyQuery.SQL.Text rows IntToStr(MyQuery.RowsAffected)); end;日志的价值不只是排错。我接手过一个慢查询单条 SQL 在 MySQL 命令行里执行只要 20 毫秒程序里却要 2 秒。打开 Trace 一看组件在 Open 之前额外执行了 SELECT COUNT(*)是 DBGrid 分页自动生成的总行数统计。这种问题如果不看原始语句怎么调 MySQL 都没用。日志就是组件的黑匣子记录仪该开的时候就开。生产环境不要开 Trace。文件 IO 在高频查询下会变成新的性能瓶颈而且日志文件会无限膨胀。我的习惯是平时关闭只在复现问题时刻打开打开前先看磁盘剩余空间跑完问题就关。4.4 裁剪组件包设计期包和运行时包分开分发源码版的组件包天然分成两类设计期包给 IDE 用的运行时包给程序用的。开发团队内部协作时我建议只分发运行时包加源文件设计期包只在需要调整组件属性的开发者机器上安装。这个边界能避免一个经典翻车场景——某个同事装错包IDE 启动报一堆找不到类然后他重装整个 IDE。分发时给文件列一个对应表会省很多事。运行时 .bpl 放到程序目录或系统路径.dcp 放到开发机的 Library 搜索路径里.pas 放进版本库但不参与程序编译路径。这样新成员加入团队时照着表拉取源码、编译包、配置搜索路径半小时内能把环境搭起来。如果发现编译报错提示某个 .pas 找不到先检查他本地的 Library path 是不是还是旧的这个排在排查顺序第一位。裁剪的另一个维度是版本管理。我给源文件打了 git tagcommit message 里写明改了什么、为什么改。这样程序出问题时能根据 bpl 文件的时间戳找到对应的源码版本。曾经有一次排查线上问题翻到源头发现改的是三周前某次调整靠的就是这个习惯。5. 避坑清单MyDAC v5.10 最常见的 5 个翻车现场5.1 现象装了包组件面板就是没有 MyDAC 页这是拿到源码版后第一个高频翻车点。装完了、编译也过了、IDE 没有报错但打开组件面板找不到 MyDAC 那一页搜遍所有分类也没有。原因有两个。一是把运行时包和设计期包搞反了Install 动作加在了运行时包上设计期包只是 Compile 了但没有安装IDE 组件面板只从设计期包注册类。二更隐蔽IDE 的 Component Install Packages 列表里已经存在这个包但包文件被替换过新编译的版本没有注册信息界面上的组件页也被挤掉了。解决先卸载所有已安装的 MyDAC 相关包然后先编译运行时包再单独打开设计期包右键 Install。安装完成后到 Component Install Packages 里确认对应条目存在再把源文件目录里的 .dcr 一并放进 Library path。5.2 现象编译提示找不到某个 .pas 文件开发机新装环境、重新拉取源码后打开工程编译IDE 提示某路径下找不到 MyDAC 的某个 .pas 文件但搜索整个磁盘发现文件明明在。原因Library path 只加了 Source 根目录而部分 .inc、.pas 放在 Source 的下层子目录里IDE 的自动搜索覆盖不到。另一个常见原因是当年的包依赖某个公共路径不同机器的环境变量指向不一样。解决把 MyDAC 源文件的根目录加进 Library path而不是只加第一层确认环境变量里没有残留旧的 Delphi 库路径编译报错后把报错信息里那个文件取出来按路径逐层对照找到它实际所在的位置再加进去。这个翻车一般几十分钟内能解决最怕的是找不到规律后重装 IDE。5.3 现象连接本机报 Cant connect through socket /tmp/mysql.sock程序里明明写着 127.0.0.1老组件却一头扎进 socket 文件路径里提示连不上 /tmp/mysql.sock。尤其在使用 Wine 或其他兼容层跑 Delphi 程序的 Linux 环境里容易出现。原因MySQL 客户端库默认优先走本地 socket 文件而组件把 localhost 或空 Server 解析成了 socket 连接。socket 文件路径不对或者 MySQL 服务端没开 TCP 监听就报这个错。解决Server 一律写成 127.0.0.1强制走 TCP如果非要走 socket在 Server 字段里填 socket 文件的绝对路径并确认 MySQL 服务端配置了相同路径。排查时先用命令行工具确认 MySQL 到底监听在哪再回头对组件参数。5.4 现象中文乱码连接参数和表字段都对了还是乱表字符集是 utf8连接 CharSet 也写了 utf8代码里读出来还是乱码或者写进去的字符串变成问号。原因老版本 MyDAC 在 Delphi 2007 以下环境返回的是 AnsiString字符串按连接字符集解码后又经过了 Delphi 自身的本地代码页转换两头编码不一致就乱了。这种问题不在 SQL 层而在组件返回值与 Delphi 字符串类型之间的转换。解决先确认 MySQL 服务端的 character_set_server 和表字符集用 SHOW VARIABLES LIKE character_set% 对照。连接 CharSet 写成与服务端一致的值别用 utf8mb4老组件的握手报文里这句话容易不被识别。把程序的本地代码页统一设置为 UTF-8或者干脆升级到 Delphi 2009 以上从源头解决字符串类型问题。实在绕不过就在源码层把返回字符串的解码逻辑补上这是我唯一建议改源码的字符集场景。5.5 现象连 MySQL 8 报认证插件不识别新库新环境MySQL 8 已经上线但 v5.10 组件连上去直接报 Authentication plugin caching_sha2_password 不能加载或不能识别。原因v5.10 的认证协议停留在 mysql_native_password 时代MySQL 8 默认的 caching_sha2_password 插件它不认识。这不是连接参数能解决的问题是协议层代差。解决短期在 MySQL 端把业务账号改回 native 认证方式执行一句 ALTER USER 即可ALTER USER app_user% IDENTIFIED WITH mysql_native_password BY your_pass;代价是这台 MySQL 的账号口令走老认证插件安全性弱一些内网环境可以接受。长期方案是把 MySQL 保持在 5.7或更换支持 MySQL 8 的新版 MyDAC。如果你现在正准备上新系统直接选新版本组件不要在 v5.10 上挣扎。老组件配新库是代差问题不是参数问题换组件比改源码划算。6. 交作业前先验证在 Docker 里搭 MySQL 回归环境6.1 用一条 docker run 起一个干净的 MySQL 5.7环境不可复现是排查数据库问题的最大障碍。我现在的做法是先起一个干净的 Docker MySQL 5.7再拿编译好的组件包连接它。MySQL 5.7 默认认证插件是 mysql_native_password和 v5.10 处在同一个时代最贴近老组件实际生产环境。# 起一个 MySQL 5.7 容器把宿主 3307 映射到容器 3306 docker run -d --name mydac-test \ -e MYSQL_ROOT_PASSWORDroot123 \ -e MYSQL_DATABASEregression \ -p 3307:3306 \ mysql:5.7端口映射到 3307 是为了避开本机可能已有的 MySQL让验证环境跑在一个独立端口上。连接时把 Server 写成 127.0.0.1Port 写成 3307其余参数和正式库保持一致。这样搭起来的环境能反复删建验证完一个猜测就删掉重来不污染本机数据。6.2 回归清单把最容易翻车的五个点过一遍环境起好后我会用一个最小 Delphi 工程按下面五条过一遍每条都不复杂但能覆盖 v5.10 在真实项目里八成的问题面连接与断线重连启动时连接一次然后 docker stop 容器再触发重连看组件的错误提示和第二次连接是否成功。存储过程调用建一个带输入输出参数的存储过程用 TMyStoredProc 调用并读回输出参数。时间字段边界查询含 NULL 的 datetime 字段看组件返回的是不是预期值有没有抛异常。中文读写写一条带中文的数据再读出来逐字节对比验证字符集链路。事务回滚开事务执行两条写操作中途故意失败rollback 后查数据库确认没留下半截数据。这五条跑完组件的底子就摸清了。最后一件事是把我这个验证工程连同回归清单一起提交到版本库下次拿到新控件或改完源码包先跑这套流程再上真业务。源码包好不好用不是看它有多少功能而是看你能不能在自己的环境里稳定复现一遍连接、读写和事务。这是我从血泪经验里沉淀下来的习惯。希望帮到你。本文还有配套的精品资源点击获取