企业官网建设流程全解析

简介：UniDAC 10.3 源代码包专为 Delphi 12、Free Pascal 3.3.1 与 Lazarus 3.9.9 打造，是面向 Delphi 控件开发者的通用数据访问组件。它能够统一连接 MySQL、Oracle、SQL Server 等主流数据库，让开发者无需关心底层协议差异即可完成数据读写，适合需要跨数据库移植或二次定制数据层的项目，也适合多数据库并存的业务场景。压缩包共收录 2000 个文件，总体积约 231.35MB，其中以 1960 个 hpp 头文件为主体，辅以 cpp 源文件、sql 脚本、txt 说明和 html 文档，对应组件接口声明、底层实现、建表脚本、安装说明与更新历史；核心目录涵盖 Source 源码、Demos 示例、Doc 文档、Lib 编译库、Http 网络模块及 DbToolsInterfaces 接口定义。Demos 提供可直接运行的参考程序，Doc 内含 API 参考，History.html 记录版本迭代，Readme.txt 给出安装步骤，对深度理解组件运行机制非常有帮助；已有 139 人学习下载，适合具备一定 Delphi 基础、希望掌握组件源码并进行功能扩展的中高级开发者。

1. 拿到 UniDAC 10.3 源码包后，先拆文件名再动手

拿到delphi 12 控件之UniDAC10.3-Source-for-D12-fpc331-Laz399-20241005-ok时，我第一反应不是解压，而是把文件名拆开看：这是 UniDAC 10.3 的源码包，面向 Delphi 12、FPC 3.3.1 和 Lazarus 3.9.9，出包日期 20241005。对使用者来说，这意味着你拿到的不是装完就能用的二进制控件，而是一套可以自己编译、单步调试、并在两个 IDE 之间维持同一套数据库访问代码的组件库。Delphi 12 里想把 SQLite、PostgreSQL、SQL Server 换成同一个接口，还保留连接池、事务和数据感知控件的体验，UniDAC 源码包就是冲这个场景来的。下面就从编译链路开始，把这套包怎么装、怎么配、哪里会翻车讲透。

2. 读懂 UniDAC 10.3 源码包的编译前提：统一连接层和组件职责

2.1 一个 TUniConnection 遮掉多家数据库协议差异

Delphi 12 里写数据访问，最常见的组合是 ADO、FireDAC、DBX 三选一。它们不是不好，而是切换数据库时需要同时改连接组件、驱动和数据类型的映射，迁移成本并不低。UniDAC 的做法是在这层之上再做一次抽象：不管底层是 Oracle、SQL Server、MySQL、PostgreSQL、SQLite 还是其他数据库，你面对的始终是同一个 TUniConnection，通过 ProviderName 属性切换数据库类型。这条抽象恰恰是源码包存在的理由——数据库适配细节写死在 Provider 单元里，业务代码只依赖一套接口。

我第一次认真用这套包是某项目X要同时交付 SQLite 单机版和 PostgreSQL 服务器版，两个版本共用同一套界面和查询逻辑。用 FireDAC 也能做，但到了 FPC 3.3.1 和 Lazarus 3.9.9 那边，驱动形态没法完全同步；换成 UniDAC 之后，业务层只出现 TUniConnection 和 TUniQuery，数据库切换就只剩改 ProviderName 和连接参数。这段经历给我的选型结论是：先别纠结组件本身复杂不复杂，先确认交付环境里有没有“同一套代码跑两种数据库”的需求，有，才值得上这层抽象。

最小连接代码长这样：

var UniConn: TUniConnection; begin UniConn := TUniConnection.Create(nil); try UniConn.ProviderName := 'PostgreSQL'; // 分发入口：决定底层协议 UniConn.Server := '127.0.0.1'; UniConn.Port := 5432; // PostgreSQL 默认端口 UniConn.Database := 'testdb'; UniConn.Username := 'postgres'; UniConn.Password := 'postgres_pass'; UniConn.Connect; UniConn.Disconnect; finally UniConn.Free; end; end.

这里的 ProviderName 就是分发入口：源码包里对应的 Provider 单元会把通用属性翻译成该数据库的原生连接协议。Port 在 PostgreSQL 下默认 5432，到 SQLite 下会被忽略，SQLite 只要 Database 指向文件路径。代码里我没有设 LoginPrompt，保持默认 False，连接参数完全由代码接管，自动化和无人值守部署时不会弹出登录框。市面上不少 Delphi 连接组件默认会弹认证窗口，这个默认值差异常常是新手第一次连数据库反而被卡住的原因。

这段代码的另一个观察点是 TUniConnection 不需要预先指定端口。如果你把 Port 留空，provider 会用自己的默认值，PostgreSQL 是 5432，MySQL 是 3306，SQL Server 是 1433。写死端口的好处是能避免数据库实例跑在非默认端口时来回试错，坏处是一旦迁移环境就要改代码。我一般把连接参数集中放在一个初始化函数里，端口和服务地址从外部配置读取，这样源码包本身编译一次后，后续只改运行配置，不用重新编译程序。

2.2 Source 包与 Setup 安装包的差别：自由度与风险

很多人看到控件包带 Source 字样，第一反应是“为什么不安一个 Setup 一步到位”。这里要区分两种交付形态。Setup 安装包通常把编译好的 BPL、DCP 和 IDE 插件直接写到 IDE 目录，打开组件面板就能用，但你想跟源码时只能跟到公开接口，真正实现被编进了二进制里。Source 包给你的是完整 Delphi/FPC 源代码，编译和安装由你自己在环境完成，代价是要自己管依赖顺序，换来的是能改源码、能在 provider 内部打断点、能跨 IDE 复用同一份实现。

把两种形态的差异列成一张表，方便你判断这个包值不值得进入技术选型：

这张表后面讲到 Lazarus 时会继续展开。简单说，项目只钉在某个 IDE 版本上，装 Setup 省事；团队里一半 Delphi 12、一半 Lazarus 3.9.9，源码包是唯一能两边同步的形态。还有一个经验：标题里那个 20241005 日期别忽略，框架组件不是每天都有快照，能针对 D12、fpc331、Laz399 三套目标做适配，说明厂商或打包者至少把这套源码完整编译回归过。收到包先看文件修改时间是否落在 20241005 前后，这比读 README 更能判断源码新鲜度。

2.3 从源码单元看 provider 分发机制

UniDAC 的源码目录通常按模块拆分：连接、数据源、查询、脚本、监控各自成目录，Provider 目录再按数据库分开放。编译时不会把十几个数据库驱动全编进去，它靠条件编译和运行时注册决定最终包里留下几个 Provider。看这套机制，比看任何功能清单都更能判断某个数据库支持得好不好。

在 Windows 命令行，我一般会先做这一步：

# 查看 FPC/LCL/Windows 相关条件编译分支，确认源码有对应适配 grep -rn "FPC_VERSION\|MSWINDOWS\|LCL" ./Source | head -30

这条命令会列出源码里和 FPC 版本、Windows 平台、LCL 相关的条件编译行。作用有两个：第一，确认这个 20241005 版本确实给 FPC 3.3.1 留了分支，不是拿旧代码充数；第二，找出 LCL 相关单元，这些单元在 Delphi 里不会被编译，但在 Lazarus 里会参与构建。如果你看到{$IF FPC_VERSION >= 331}这类定义，说明源码对开发版 FPC 做了专门适配，比那些“理论上能用”的包靠谱得多。

有一点必须提醒：文件名里同时出现 D12 和 fpc331，并不表示能用同一个编译产物同时服务两个 IDE。Delphi 12 编译出来的是带 Delphi 运行时的二进制，Lazarus 编译出来的依赖 FPC 运行时，二者不能互换。同一份 .pas 源码分别走两条编译链，才能得到两组结果。我见过有人把 Delphi 12 的.bpl复制进 Lazarus 目录，指望省掉编译，结果 IDE 直接起不来。后面几章讲的编译操作，都是按这个“一份源码、两条编译链”的前提来做的。理解到这一步，再来谈 Delphi 12 下的安装步骤就不容易出错。

3. Delphi 12 下编译 UniDAC 10.3 源码：包顺序、库路径和最小连通测试

3.1 把解压目录和 IDE 库路径安排成可复现的状态

先建一个干净的目录。我是把所有文件放到D:\Libs\UniDAC103这类短路径下，不走桌面，也不走带空格的目录。Delphi 编译器对路径空格和中文路径的容忍度一直在改善，但第三方包的 .dpk 里大量使用绝对或相对包含指令，遇到带空格路径时，INCLUDE 搜索经常翻车。把这一问题堵在开始，能省掉后面一半的报错。

用 PowerShell 把源码复制并陈列包文件：

$base = "D:\Libs\UniDAC103" $pkg = ".\UniDAC10.3-Source-for-D12-fpc331-Laz399-20241005-ok" New-Item -ItemType Directory -Force -Path $base Copy-Item -Recurse -Force $pkg $base # 全量复制源码到无空格路径 # 列出三类包文件，用于区分运行时包和设计时包 Get-ChildItem $base -Recurse -Include *.dpk,*.dproj,*.lpk | Select-Object FullName, Name | Format-Table

这里Copy-Item的-Recurse会保留源码目录结构，-Force避免半路中断；最后一条命令把.dpk、.dproj、.lpk全部列出来，让你一眼看清楚包内提供的工程文件类型。.dproj是 Delphi 的 MSBuild 工程，.dpk是传统包工程，Lazarus 那侧对应.lpk。如果你的包目录里同时存在这三类文件，说明这个源码包就是为了 D12 和 Lazarus 双平台维护的。

列出结果后，先不要急着在 IDE 里双击。回到 Delphi 12 的Tools > Options > Library页，把$base\Source加进 Library Path，并把$base\Packages加进 Browsing Path。Library Path 影响编译时的单元搜索，Browsing Path 只影响查看源码。很多教程只让加 Source，结果设计时包编译到一半找不到另一个分支下的.inc，就是搜索路径不全。加完路径后重启一次 IDE，让缓存重新加载，再开始编译。

3.2 运行时包先编，设计时包后装：找到正确的 dpk/dproj

UniDAC 这类组件安装必须遵守一个顺序：先编译运行时包，再编译设计时包，最后 Install。运行时包通常不带dcl前缀，设计时包带dcl前缀，后者的职责是把组件注册到 IDE 组件面板，并链接到已经编译好的运行时包。顺序反了会出现什么情况？我先编译设计时包，它依赖的运行时包还没生成，于是一大串 Unit not found 冲出来，你根本分不清是路径问题还是包问题。

在刚才的 PowerShell 输出里，把带dcl的和不带dcl的分开看：不带的是运行时部分，带的是设计时注册部分。我通常先打开运行时包对应的.dproj或.dpk，在项目管理器里右键Compile，注意这里选 Compile 不是 Build。Compile 只编译当前包，Build 会级联重编所有依赖。第一次装新环境用 Compile 更容易定位问题，因为你希望每一步的依赖都从已经编译好的包里拿，而不是让 IDE 顺手把一大堆依赖也重编一遍，报错时反而不知道错在谁身上。

运行时包编译通过后，再打开带dcl的设计时包，同样先 Compile，随后点Install。Install 的时候 IDE 会要求确认是否安装到活动包集合，确认后组件就会出现在组件面板。这里有一个常见误导：很多包总喜欢把所有数据库 provider 打进同一个包里，编出来的二进制巨大，Install 时非常容易因为内存不足或残留缓存失败。如果这个源码包确实把 provider 分成了多个包，你就按需逐个编译，不要贪多。只要 TUniConnection、TUniQuery 这个主包在，连接验证程序就已经可以写了。

3.3 编译后第一次连通测试：TUniConnection 连 SQLite

安装完成后，先不急着往窗体上拖组件，我习惯写一个最精简的控制台程序做连通测试。这样能排除窗体创建、数据感知控件、界面线程等干扰，纯粹验证“源码编译出来的 provider 能不能真的连上库”。项目里新建一个控制台工程，写入：

program CheckUniDAC; {$APPTYPE CONSOLE} uses System.SysUtils, Uni, UniProvider, SQLiteUniProvider; // 显式注册 SQLite provider 单元 var Conn: TUniConnection; begin Conn := TUniConnection.Create(nil); try Conn.ProviderName := 'SQLite'; // 指定数据库类型 Conn.Database := 'C:\Temp\unidac_test.db'; // 指向物理文件 Conn.Connect; Writeln('connected: ', Conn.ServerVersion); Conn.Disconnect; finally Conn.Free; end; end.

这段代码里有几个关键点。uses里的SQLiteUniProvider必须存在，否则即使ProviderName设成'SQLite'，也会在连接时报 provider 找不到。这个机制不看Uni主单元，要看对应的 provider 注册单元是否被链接进工程。UniDAC 不会把所有 provider 全编进去，你用了哪个数据库，就把哪个注册单元写进 uses，这是它和 FireDAC 把所有驱动静态链接的明显区别。

SQLite 的Database指向一个具体磁盘文件，文件不存在时多数 provider 会新建空文件，如果你期望它报错而不是新建，应该提前检查文件存在。连接后我读取ServerVersion，用来确认连上的不是内存空壳，而是真正初始化完成的 SQLite 引擎。最后执行Disconnect并Free，保证进程退出时没有未释放句柄。这一步跑通之后，再回 IDE 拖 TUniConnection 到窗体上，把同样的属性填进对象监视器，基本就是照搬。

这里可以再补一句选型经验：测试 SQLite 而不是 PostgreSQL，是因为 SQLite 不需要额外装服务端，能让“源码包本身编译是否成功”和“网络数据库服务是否可用”这两件事解耦。如果你的目标环境是 Oracle 或 PostgreSQL，连通测试不通过时，你无法判断是包的问题还是数据库服务的问题。SQLite 通过后，再逐个加其他 provider，哪个不过就单独排查哪个。

4. 把同一份源码搬到 FPC 3.3.1 + Lazarus 3.9.9：lpk、lazbuild 和条件编译差异

4.1 FPC 3.3.1 与 Lazarus 3.9.9 的组合为什么值得注意

FPC 3.3.1 不是稳定版，而是开发版本；Lazarus 3.9.9 同样不在长期支持分支里。正常情况下，生产项目会选稳定版 FPC 搭配稳定版 Lazarus，那为什么源码包标题要特意写 fpc331 和 Laz399？因为 UniDAC 这种大组件，内部条件编译分支非常多，每一条{$IF FPC_VERSION}都可能决定某个方法是否启用。用旧稳定版 FPC 编译 20241005 这份源码，大概率能过，但包内为 3.3.1 预留的新特性分支不会被激活；反过来，如果你已经在 Laz399 上建了项目，就必须保证源码里针对 FPC 3.3.1 的分支能被正确编译。

我实际遇到的情况是：某跨平台系统在 Windows 上用 Delphi 12 开发，在 Linux 上计划用 Lazarus 发布。Lazarus 装的是 3.9.9，因为项目里用到了新版 LCL 的某个控件行为。UniDAC 源码包标题恰好覆盖这套组合，于是我把编译环境直接锁定为 Laz399。如果你的 Lazarus 版本和源码包的适配版本不一致，请优先考虑升级或降级 Lazarus，而不是强行在旧版上编译新源码。多数第三方组件的适配问题，最后都收敛到 IDE 版本不匹配这一个原因上。

4.2 用 lazbuild 从命令行安装 UniDAC 的 lpk

在 Lazarus 里安装组件，常见有两条路：图形界面打开Package > Open Package File找到.lpk，编译后点 Install；或者用命令行lazbuild完成同样操作。命令行适合反复重装，比如每次拿到新源码后自动安装，省去手工点击。我一般这样用：

# 安装 UniDAC 包并重建 Lazarus IDE lazbuild --add-package="/path/to/UniDAC.lpk" --build-ide

--add-package接受 lpk 的绝对路径，--build-ide让 lazbuild 在添加后重建 Lazarus IDE。重建完成后，重新打开 Lazarus，组件面板里就会出现 UniDAC 相关控件。这条命令的常见失败点是 lazbuild 不在 PATH 里，Lazarus 安装目录下的lazbuild.exe（Windows）或lazbuild（Linux/macOS）需要先加入 PATH。另一个失败点是路径写错后，命令可能只提示找不到文件，不会告诉你具体是哪一个依赖缺失，所以执行后留意一下终端输出有没有出现 Success 字样。

如果你不希望重建 IDE，只想验证 lpk 能编译，可以用：

# 仅注册不重建，用于快速验证 lpk 是否能通过解析 lazbuild --add-package="/path/to/UniDAC.lpk"

不带--build-ide时，它只把包加入 IDE 的包列表，不触发重建。这样看起来更安全，但要注意：仅 add 不 build，IDE 里组件面板不会更新，运行时包也没有被编译。我通常先跑一次不带 build 的，确认包文件本身没问题，再带--build-ide跑一次，把安装和编译分开排查，哪一步挂了一目了然。

4.3 同一份业务代码在 Delphi 和 Lazarus 下的差异点

UniDAC 的跨平台设计让业务代码主体可以共用，但真正落地时还是有几个缝隙需要补。最典型的是数据库文件路径。Delphi 在 Windows 上开发时下意识写C:\Temp\test.db，这段代码拿到 Lazarus 的 Linux 版就崩。我的做法是把路径抽象成平台分支：

{$IFDEF MSWINDOWS} UniConnection1.Database := 'C:\Temp\test.db'; {$ELSE} UniConnection1.Database := '/tmp/test.db'; {$ENDIF}

这在 Delphi 和 Lazarus 下都能编译，也是 FPC 条件编译最常见的用法。另一个差异是ParamByName的参数绑定。UniDAC 在 Delphi 下默认参数名大小写不敏感，但 FPC 3.3.1 对接口类型检查更严格，如果你的 SQL 里写:active，代码里也用'active'，一般没问题；如果开发中有人写过:Active，就会偶尔出现奇怪的参数值错位。统一用同一大小写写参数名，能省掉很多 FPC 下的玄学错误。

第三个差异和数据库驱动动态库有关。Delphi 的 SQLite provider 可能已经静态链接了 sqlite，而 FPC 分支更倾向动态调用系统库。在 Windows 上，你把sqlite3.dll放到 exe 同目录即可；在 Linux 上，要么用系统包管理器安装libsqlite3，要么把.so放到LD_LIBRARY_PATH指向的目录。这一条看着像部署问题，实际是源码包在 FPC 下最常见的运行时报错来源之一。完成了这些差异处理，同一份读写代码就能在两个 IDE 下维持，剩下的是按环境各自编译，而不是维护两套代码。

5. UniDAC 10.3 源码包编译与运行的五个高频坑：现象、原因和处理

5.1 编译报 was compiled with a different version of System：旧缓存比代码更不讲理

现象：安装 UniDAC 运行时包时，IDE 报错说某个已编译单元和当前 RTL 版本不匹配，后面的编译链全部中断。

原因：这个错误绝大多数不是源码的问题，而是 IDE 和第三方包的 DCP/DCU 缓存残留。先编译过程序后升级了 Delphi 小版本，或者把源码包换了个目录复制，旧.dcu、.dcp文件还留在原来位置，编译器优先命中了它们。

解决：先把源码包目录和 IDE 库路径里所有*.dcu、*.dcp、*.bpl清理干净，再重新编译。Windows 下我通常用 PowerShell 删这几类文件：

# 清除旧编译产物，避免缓存命中共它目录 Get-ChildItem -Path "D:\Libs\UniDAC103" -Recurse -Include *.dcu,*.dcp,*.bpl | Remove-Item -Force

删除后重新打开包工程并 Compile。注意一定先把 IDE 里已加载的包全部关闭，否则 BPL 文件正在被占用，删除操作会失败。这个坑的隐蔽之处在于，报错行往往指向某一个很普通的单元，新手会去查源代码差异，查半天发现源码根本没变，变的是缓存。

5.2 组件面板没出现 UniDAC 控件：设计时包和运行时包没配对

现象：编译过程全程无报错，Install 也提示成功，但打开组件面板找不到 TUniConnection、TUniQuery 这类控件。

原因：设计时包的版本信息头和运行时包不一致，或者 Install 时安装到了错误的包集合。另一个常见原因是设计时包的 uses 里没有包含注册单元，导致 IDE 不知道要注册什么组件。

解决：先重新编译一次设计时包，确认它依赖的运行时包就是刚编译的那个版本。然后在项目管理器里查看设计时包的 Requires 列表，里面应该能看到运行时包的名称。如果列表里没有，说明设计时包正在链接另一份运行时包，通常是旧包仍留在 Library Path 里。把旧目录从 Library Path 移走，再 Build 一次设计时包。最后把 IDE 里所有和 UniDAC 相关的包卸载，重新打开设计时包执行 Install。这一套做完，组件面板还空着，就去设计时包的注册单元里检查 RegisterComponents 方法的第一个参数，是不是误写成了某个不存在的页面名称。

5.3 Provider 找不到：uses 子句漏了数据库注册单元

现象：编译通过，运行到 Connect 时抛出类似 Provider 'SQLite' not found 的运行时错误，或者返回错误代码，但 IDE 里明明能看到组件。

原因：UniDAC 不像某些组件把所有数据库驱动全部预编译进一个包，它按 provider 分开注册。如果你的工程 uses 里只写了Uni，没有写SQLiteUniProvider，编译期没有任何提示，因为类引用不在源码表面；到运行时真正要创建 provider 时，注册表是空的。

解决：按照第 3 章最小程序里的写法，在 uses 里显式加上对应 provider 注册单元。比如 PostgreSQL 就用PostgreSQLUniProvider，SQL Server 用SQLServerUniProvider，MySQL 用MySQLUniProvider。我自己的习惯是写一个集中的 DataModule，在它的单元 uses 里把当前项目用到的两到三个 provider 全部列出来，以后换数据库只改 DataModule，不会散落到每个窗体。要注意 provider 单元名大小写和源码包里的实际文件名一致，特别是从 Linux 上解压分发到 Windows 的包，文件名大小写容易被折腾，先打开 Source 目录确认。

5.4 FPC 下连接 SQLite 报动态库缺失：DLL/SO 路径不在搜索范围

现象：同一份代码在 Delphi 12 下能连 SQLite，在 Lazarus 3.9.9 编译后运行，程序启动或连接时报找不到sqlite3.dll（Windows）或libsqlite3.so.0（Linux）。

原因：FPC 分支的 SQLite provider 默认动态加载数据库引擎库，而 Delphi 分支可能静态链接了内部实现。这不是 UniDAC 独有的，而是 FPC 生态下 SQLite 驱动的一致行为，包括内置的 sqlite3ds 也一样。

解决：Windows 上把和目标程序位数一致的sqlite3.dll放到 exe 同目录。32 位程序配 32 位 DLL，64 位程序配 64 位 DLL，混用会在LoadLibrary阶段直接失败。Linux 上确认系统里有对应库：

# 检查系统能否找到 sqlite3 动态库 ldconfig -p | grep sqlite3

如果输出为空，安装libsqlite3后再试；如果库存在但程序还是连不上，检查可执行文件是不是 32 位而系统只有 64 位库。这里最容易翻车的是把 32 位 DLL 放到 64 位程序目录，系统不会给出清晰提示，只有一句加载失败。遇到这种情况，直接用工具看依赖，或者直接在代码里调用LoadLibrary测试同一个 DLL，能快速定位到底是路径问题还是位数问题。

5.5 连接字符串和连接属性混用导致的行为不一致

现象：同样的连接参数，有的人写在ConnectionString里，有的人写在Server、Database属性里，结果两个环境行为不一样，一个能连一个不能连。

原因：UniDAC 的连接属性在 Connect 前会合并成一份连接字符串，如果两处同时写，后写入的会覆盖先写入的，而且覆盖方向在不同 provider 下不完全一致。这是一个容易引发“明明看到参数是对的，连不上”的坑。

解决：统一管理连接参数。我一般只在代码里赋 ProviderName 和连接属性，不手工拼ConnectionString；必须用连接字符串时，就只用它，不再同时写Server等属性。这样连接行为是单一来源。调试时可以在 Connect 后读取UniConnection1.ConnectionString，把实际生效的参数打印出来，和你的预期对比。这一步常常能直接看出某个参数被覆盖成了别的值。

6. 进阶使用：把源码包变成你的私有数据库适配器

源码包真正值钱的地方，是当你不按厂商预想的方式使用时，还有退路。官方支持的数据库列表里没有你内网那套老系统时，常见的做法是复制一个最接近的 provider 单元到自己的目录，改协议细节和参数映射。我在某项目X上就用过这套思路：底层是个只读接口，协议接近 MySQL，我复制MySQLUniProvider后改掉认证包格式，业务层完全不用感知。这个动作在二进制安装包下根本做不了，因为没有源码，你连 provider 内部怎么发包都看不见。

配合源码单步调试，我强烈建议把TUniSQLMonitor接进连接：

UniConnection1.Monitor := UniSQLMonitor1; // 绑定监控组件 UniSQLMonitor1.AutoSave := True; // 自动落盘，不依赖界面 UniSQLMonitor1.FileName := 'sql_trace.log'; // 日志文件路径

打开sql_trace.log，你能看到程序实际发给数据库的每条 SQL、执行参数和返回值。验证自定义 provider 是否正确，不是看界面有没有报错，而是看发出的 SQL 是不是预期的那条。这个方法在调试存储过程和参数绑定时特别有用。

最后说一个我自己的习惯：每次升级源码包前，先把新旧两个版本的编译日志各自保存，再对包内改动过的.pas做一个 diff，确认没有偷偷改掉依赖 API。这个习惯帮我在一次打包日期相近的版本切换中避开了 provider 初始化顺序的变化。毕竟源码包用得好，是把控制权拿回自己手里；用得不好，是把别人的改动直接接进生产环境还无处追责。希望帮到你。

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