Object Pascal指针实战：类型规则与二进制帧解析

接手一个跑了七八年的老工控项目时，最让我头疼的不是几万行的业务逻辑，而是一个叫ParseFrame的函数——里面密密麻麻全是PByte、@、Inc(P, 4)这样的写法。当时我第一反应是"这都什么年代了还用指针"，结果改了三版，最后还是老老实实把指针那套规则重新梳理了一遍，因为那段代码要处理的是一帧一帧的二进制报文，用字符串和数组硬套，性能直接掉一半。这也是我想写这篇笔记的原因：Object Pascal 里的指针并没有过时，它只是躲到了那些真正需要贴着内存干活的角落里。这篇内容适合已经能写 Delphi 基本语法、但一看到^和@就心里发虚的朋友，也适合那些维护老代码、需要读懂别人指针写法的同行。我会把类型化指针和无类型指针的区别、New/GetMem 两套堆 API 的取舍、字符指针和字符串的边界、二进制帧解析的完整写法、以及我自己踩过的几个坑，一条一条摊开讲清楚。指针这东西，规则不多，但每一条都是硬规则，违反哪条都会在某个深夜给你一个访问违例。

1. 为什么在 Delphi 11 里还得把指针捡起来

1.1 从一次莫名其妙的访问违例说起

先说个真实场景。某公司的上位机软件，跑在客户现场，每隔两三天崩一次，错误信息是Access violation at address 004A1B2C in module 'xxx.exe'. Read of address 00000010。日志里什么都看不出来，因为崩的位置在第三方串口库的回调里。折腾了快两周，最后定位到的原因是：回调函数的参数缓冲区，被回调方在返回后立刻释放了，而我们的代码把那个PByte存到了一个成员变量里，打算"稍后异步处理"。

这就是指针最典型的坑：它只是一个数字，一个地址值，它不知道自己指向的东西还在不在。字符串、动态数组、对象引用在 Delphi 里都有引用计数或生命周期管理兜着你，指针没有。你把地址存下来，就等于把"这块内存还有效"这个承诺，从编译器手里抢过来自己扛。

反过来讲，指针的价值也在这儿。它让你能用最小的代价表达"我从这块缓冲区的第 17 个字节开始读 4 个字节"这件事，不用拷贝、不用切片、不用构造新对象。对于协议解析、图像处理、加密运算这类场景，这个能力省下来的时间和内存是实打实的。

1.2 哪些场景你绕不开指针

我梳理了一下这些年真正必须用指针的地方，大致是这几类：

除了这几类，日常 CRUD 业务里确实可以一辈子不碰指针，这没什么好羞耻的。指针不是"高级"，它只是另一种工具，用在对的地方才叫本事，用在不该用的地方就是给自己埋雷。我见过有人为了"显得专业"，把简单的TStringList遍历改成指针遍历，结果代码可读性暴跌，性能提升不到 3%，这种就是纯粹的技术表演。

1.3 Pointer 和 ^T 是两种东西，别混为一谈

Object Pascal 里的指针分两大类，这个区分是后面所有内容的基础。

第一类是无类型指针Pointer。它就是一个纯粹的地址，编译器不知道它指向什么，所以你不能写P^去解引用（实际上P^语法上不允许对Pointer使用），也不能对它做Inc步进——因为编译器不知道"一步"该走几个字节。

第二类是类型化指针，比如PInteger = ^Integer、PByte = ^Byte、PMyRecord = ^TMyRecord。它们带类型信息，所以支持解引用、支持按类型大小步进、支持赋值时的类型检查。

type PInteger = ^Integer; // 系统单元已定义 PByte = ^Byte; // 系统单元已定义 TPointRec = packed record X, Y: Integer; end; PPointRec = ^TPointRec; var P: Pointer; PI: PInteger; Value: Integer; begin Value := 42; P := @Value; // 无类型指针，只知道地址 PI := @Value; // 类型化指针，知道指向 Integer Writeln(PI^); // 输出 42，可以解引用 // Writeln(P^); // 编译不通过，Pointer 不能直接解引用 Writeln(Integer(P^));// 先转成具体类型才行 end;

这段代码里最值得琢磨的是P := @Value这一句。在默认编译选项下，@运算符返回的是无类型Pointer，赋值给PI时编译器悄悄做了一次隐式转换。这个"悄悄"就是后面很多诡异问题的源头，第 2 节会专门讲{$T}开关。

我的建议很简单：凡是能确定类型的场合，一律用类型化指针，不要图省事用Pointer。类型化指针能让编译器帮你挡掉一批错误，比如你把PInteger赋给PByte会直接编译失败，而Pointer转来转去编译器全程装瞎，等到运行时崩了你才反应过来。

2. @ 和 ^ 这对符号背后的实际规则

2.1 @ 取到的到底是什么

@X的意思很直白：取变量 X 所在内存的起始地址。但有几个细节新手经常搞不清。

第一，@作用于变量，不是表达式。@(A + B)这种写法在某些语法位置能过，但取到的是编译器生成的临时变量的地址，用完就废，非常危险。我见过有人写P := @(SomeFunc())，然后拿着这个指针到处跑，结果函数返回值存在寄存器里，压根没有稳定的内存地址，读出来的全是垃圾。

第二，对记录类型取址，拿到的是记录第一个字段的地址，因为记录在内存里是连续布局的（除非字段之间有对齐填充）。对packed record取址，字段之间没有填充，偏移可以直接算。

第三，对数组取址，@Arr和@Arr[0]是同一个地址，但类型不同：前者是^TArrayType，后者是^元素类型。实际用的时候几乎总是用后者。

var Arr: array[0..9] of Byte; P: PByte; begin P := @Arr[0]; // 常用写法 // P := @Arr; // 也能拿到同样的地址，但类型含义不同 Writeln(Arr[0]); // 通过变量访问 Writeln(P^); // 通过指针访问，读到同一个字节 end;

2.2 ^ 解引用的类型语义决定了你读到几个字节

P^的含义是"把 P 指向的那块内存，按 P 的基类型来解释"。这句话里的"按基类型解释"是核心。同样是同一个地址，PByte解引用读到 1 个字节，PInteger解引用读到 4 个字节，PDouble读到 8 个字节并且要按浮点格式解释。

这意味着一个非常常见的错误：把PInteger强转成PByte后忘了偏移计算。比如一块 16 字节的缓冲区，你用PByte走完前 4 个字节，然后把地址转成PInteger去读，读到的确实是这 4 个字节拼成的整数——这个转换本身没问题，问题在于很多人忘了 x86/x64 是小端序，$01 $00 $00 $00读出来是 1，而网络报文里$00 $00 $00 $01读出来是$01000000，差了 1677 万倍。这个坑第 5 节会展开。

还有一点要注意，P^除了读，还能写：

var I: Integer; PI: PInteger; begin I := 100; PI := @I; PI^ := 200; // 等价于 I := 200 Writeln(I); // 输出 200 end;

对指针解引用赋值，改的是原变量。这是指针能做"输出参数"的原理，也是它能不小心改坏别人数据的原理。

2.3 {$T-} 和 {$T+}：地址类型检查开关

这是很多人写了几年 Delphi 都没注意过的一个编译指令。

{$T-} // 默认状态：@ 返回无类型 Pointer {$T+} // @ 返回类型化指针

在默认的{$T-}下，@I得到的是Pointer，你可以把它赋给任何指针类型，编译器不会拦你：

var I: Integer; PB: PByte; begin I := 1000; PB := @I; // {$T-} 下能编译通过，但语义完全错了 Writeln(PB^); // 只读到低 8 位，1000 的低字节是 232 end;

这段代码在{$T-}下悄悄通过，运行输出 232 而不是 1000。如果你打开{$T+}，PB := @I会直接编译报错，因为^Integer不能赋给^Byte。这就是类型检查开关的价值。

我的做法是：新写的单元，在单元头部加上{$T+}。它会带来一些额外的显式转换负担，但换来的是编译期就能发现类型错配。对于那些必须做原始内存操作的几行代码，用局部{$T-}包起来，把风险控制在最小范围。这个习惯帮我省掉的调试时间，比它带来的麻烦多得多。

2.4 Inc 和 Dec 的步长由基类型决定

类型化指针支持Inc、Dec和+、-运算，步长自动按基类型大小算：

var Buf: array[0..31] of Byte; P: PInteger; begin P := @Buf[0]; Inc(P); // 前进 4 字节，等价于 PByte(P) + 4 Writeln(NativeUInt(P) - NativeUInt(@Buf[0])); // 输出 4 end;

这个特性用起来很顺手，但也埋着一个坑：如果你把指针当成"字节游标"在缓冲区里走，一定要用PByte，千万别用PInteger然后手动Inc(P, 4)去模拟字节偏移，两者混着写迟早算错。我一般的约定是：遍历缓冲区一律用PByte，需要按字段读取时临时强转，读完立刻把游标位置记下来。

3. 堆内存的三套 API，用错哪套都会出事

3.1 New 和 Dispose：成对出现才有意义

New(P)为类型化指针分配一块"基类型大小"的内存，Dispose(P)释放它。这对函数的好处是类型安全 + 尺寸自动，你不用自己算要多少字节：

type PUserInfo = ^TUserInfo; TUserInfo = record Id: Integer; Name: string; // 注意这里有托管类型 end; var P: PUserInfo; begin New(P); try P^.Id := 1; P^.Name := 'test'; // 使用 P^ finally Dispose(P); end; end;

这里有个很多人不知道的细节：New/Dispose对含有托管字段（string、动态数组、接口、变体）的记录是安全的。New会把托管字段初始化为空，Dispose会正确地减少字符串引用计数，避免内存泄漏。这一点和GetMem/FreeMem完全不同——用GetMem分配一块包含string字段的记录，然后直接FreeMem，那个字符串就泄漏了，因为FreeMem只归还内存，不调用终结逻辑。

所以我的判断标准很清晰：要分配的是"某种类型的对象"，用New/Dispose；要分配的是一块"原始大小的缓冲区"，用GetMem/FreeMem。两者别混。

3.2 GetMem 和 FreeMem：大小是你自己的责任

GetMem(P, Size)分配指定字节数的内存，FreeMem(P)释放。这里的P通常是Pointer或者某个指针类型，但编译器不管你传的类型对不对——它只看你给的大小。

var Buf: PByte; Size: Integer; begin Size := 4096; GetMem(Buf, Size); try FillChar(Buf^, Size, 0); // 必须自己清零 // 往 Buf 里读写数据 finally FreeMem(Buf); // 或 FreeMem(Buf, Size)，后者利于调试 end; end;

FillChar(Buf^, Size, 0)这一句是老手必备动作。GetMem拿到的内存里是上次谁用剩的垃圾数据，如果你直接按位解析，很容易读到莫名其妙的旧值。这一点我用血泪验证过：某个通信模块偶发解析出错误帧，查了两天，最后发现是GetMem之后没清零，缓冲区尾部残留了上一次的报文。

FreeMem有个带 Size 参数的重载版本FreeMem(P, Size)，它在某些内存管理器实现下能做一些校验。日常用不带 Size 的就够，但在调试阶段用带 Size 的版本能更早暴露"大小传错了"这类问题。

3.3 AllocMem 省事，但别当默认选择

AllocMem(Size)等于GetMem+ 自动清零，返回Pointer。写起来确实舒服：

var Buf: PByte; begin Buf := AllocMem(1024); // 已经清零 try // 直接使用 finally FreeMem(Buf); end; end;

但要注意场景。如果你打算紧接着就把整块缓冲区用Move覆盖掉，那清零这一步就是白送的性能损失。对于大缓冲区（比如几十 MB 的图像数据），这个损失是能测出来的。我的习惯是：小块、需要确定性初值的地方用AllocMem；大块、马上就要整体填充的地方用GetMem然后该填什么填什么。

3.4 内存泄漏怎么定位

指针分配忘释放导致的泄漏，最直接的检测手段是 Delphi 自带的内存管理器报告。在项目里加上这一行：

begin ReportMemoryLeaksOnShutdown := True; // 放在 dpr 主程序开头 Application.Initialize; // ... end.

程序退出时会弹出报告，列出未释放的块数和大小。注意这个机制只对 Delphi 自己的内存管理器有效，对直接调用系统 API 分配的内存不管用。

定位到具体位置靠的是在try...finally里下断点，或者用Format把分配地址和大小打出来做配对比对。我一般会在开发阶段写一对辅助函数：

var GAllocCount: Integer = 0; function DebugAlloc(Size: NativeInt): Pointer; begin Result := GetMemory(Size); Inc(GAllocCount); Writeln(Format('alloc %p size=%d total=%d', [Result, Size, GAllocCount])); end; procedure DebugFree(P: Pointer); begin if P <> nil then begin Dec(GAllocCount); Writeln(Format('free %p total=%d', [P, GAllocCount])); end; FreeMemory(P); end;

这种土办法土归土，但在没有额外工具的环境里非常顶用，几行日志就能看出哪块内存分配了没还。

4. 字符指针和字符串之间的那条线

4.1 PChar 到底是什么

Delphi 11 里string是UnicodeString，所以PChar就是PWideChar，指向一串以#0结尾的 UTF-16 字符。这一点必须记牢，因为很多人脑子里还留着 Delphi 7 时代的印象，以为PChar是单字节。

var S: string; P: PChar; begin S := 'Hello'; P := PChar(S); // 拿到首字符地址，不是拷贝 Writeln(P[0]); // 'H' Writeln(P[4]); // 'o' Writeln(Ord(P[5])); // 0，结尾的 #0 end;

PChar(S)这种写法是零拷贝的，P直接指向S内部的字符缓冲区。这带来两个后果：一是效率高，二是**S一变，P就可能失效**。比如在P还存在的时候给S重新赋值一个更长的字符串，S内部会重新分配缓冲区，P指向的就是已经释放的旧内存了。

4.2 StrPCopy 和 StrPas 的正确用法

需要把string拷进一块自备缓冲区时，StrPCopy是标准工具：

var Buf: array[0..255] of Char; S: string; begin S := 'Some text'; if Length(S) + 1 > SizeOf(Buf) div SizeOf(Char) then raise Exception.Create('缓冲区不够'); StrPCopy(Buf, S); // 拷贝并自动补 #0 Writeln(StrPas(Buf)); // 反向转换回来 end;

这里的长度检查是必须的，StrPCopy不做边界检查，缓冲区小了就是直接越界写，没有任何提示。我见过一个项目因为这个崩了半年，最后发现是某个多语言环境下字符串长度超了预期。所以上面的if判断不是形式主义，是保命的。

StrPas是把PChar转回string，它会一直读到#0为止，同样不做长度限制。如果指针指向的缓冲区里恰好没有#0终结符，它会一路读下去直到撞上非法地址——这就是很多"读字符串读崩了"的根本原因。对于不保证#0结尾的二进制数据，正确的做法是用SetLength(S, N)+Move手动构造：

var P: PByte; N: Integer; S: string; begin N := 16; SetLength(S, N); Move(P^, S[1], N); // 按字节拷贝，不依赖终结符 end;

4.3 把局部变量地址传出去，是最经典的错

这个坑我必须单独说，因为它太常见了，而且编译器完全不拦。

function GetNamePtr: PChar; var S: string; begin S := 'hello'; Result := PChar(S); // 危险！S 在函数返回时就被释放了 end;

函数返回后，S的引用计数减到 0，内存被回收，Result变成悬空指针。调用方拿它去StrPas，读到的可能是别的东西，也可能直接崩。这类问题在单线程小数据量的时候经常"看起来正常"，因为那块内存还没被重新用掉，一旦上线跑起来就是随机崩溃。

正确的做法有三种：返回string而不是PChar（绝大多数情况应该这样）、由调用方提供缓冲区、或者用GetMem分配后由调用方负责释放（明确约定所有权）。

同样的道理，不要把PChar(SomeString)的结果存进成员变量或全局变量，除非你能保证那个string的生命周期覆盖使用期。临时字符串的生命周期只在当前表达式内有效，这一点特别容易在Format、IntToStr这类函数上翻车：

// 错误示范 P := PChar(IntToStr(123)); // 临时字符串，下一秒就没了 // 正确写法 S := IntToStr(123); P := PChar(S); // S 是具名变量，活到作用域结束

4.4 用 PByte 走字节流才是正解

处理非文本数据时，一律用PByte，别碰PChar。PByte没有终结符概念，读几个字节就是几个字节，语义清晰：

var Buf: array[0..15] of Byte; P: PByte; I: Integer; begin for I := 0 to 15 do Buf[I] := I * 2; P := @Buf[0]; for I := 0 to 15 do begin Writeln(Format('%p -> %d', [P, P^])); Inc(P); end; end;

Inc(P)每次走 1 个字节，这就是"字节游标"的标准写法。后面解协议帧的时候，整个流程都是围绕这个游标展开的。

5. 手写一个二进制帧解析：完整可跑的案例

5.1 先定帧结构，再谈对齐

假设要解析这样一个帧格式（这是我编的一个模拟协议，结构在工控和通信里很典型）：

这里第一个技术决策是：用record直接映射，还是用PByte逐字段读。

用record映射看起来优雅：

type TFrameHeader = packed record Magic: Word; Version: Byte; CmdType: Byte; PayloadLen: Cardinal; Timestamp: Cardinal; end; PFrameHeader = ^TFrameHeader;

但这条路有两个问题。一是大小端，record直接映射得到的是本机字节序，x86 是小端，而协议是大端，读完还得手动交换。二是字段多、变长的时候，record表达不了Payload这种长度依赖前一个字段的情况，最终还是要退回指针偏移。

所以我的选择是：头部的定长字段可以用packed record表达布局便于阅读，但实际解析用PByte逐字段推进。这样既能一眼看出结构，又能在字节级别完全掌控。

5.2 用 PByte 逐字段推进的完整写法

type TFrame = record Version: Byte; CmdType: Byte; PayloadLen: Cardinal; Timestamp: Cardinal; Payload: TBytes; Checksum: Word; end; function Swap16(V: Word): Word; inline; begin Result := (V shr 8) or (V shl 8); end; function Swap32(V: Cardinal): Cardinal; inline; begin Result := ((V and $000000FF) shl 24) or ((V and $0000FF00) shl 8) or ((V and $00FF0000) shr 8) or ((V and $FF000000) shr 24); end; function ParseFrame(const Buf: TBytes; out Frame: TFrame): Boolean; var P, PEnd: PByte; Len: Cardinal; begin Result := False; if Length(Buf) < 14 then Exit; // 最小帧长：12 字节头 + 2 字节校验 P := @Buf[0]; PEnd := P + Length(Buf); // 1. 校验魔数 if (P^ <> $AA) then Exit; Inc(P); if (P^ <> $55) then Exit; Inc(P); // 2. 版本与命令类型 Frame.Version := P^; Inc(P); Frame.CmdType := P^; Inc(P); // 3. 负载长度（大端） Len := (Cardinal(P^) shl 24); Inc(P); Len := Len or (Cardinal(P^) shl 16); Inc(P); Len := Len or (Cardinal(P^) shl 8); Inc(P); Len := Len or Cardinal(P^); Inc(P); Frame.PayloadLen := Len; // 4. 长度合法性检查，防越界 if Len > Cardinal(PEnd - P) then Exit; // 5. 时间戳（大端） Frame.Timestamp := Swap32(PCardinal(P)^); Inc(P, 4); // 6. 负载 SetLength(Frame.Payload, Len); if Len > 0 then Move(P^, Frame.Payload[0], Len); Inc(P, Len); // 7. 校验和（大端） if P + 2 > PEnd then Exit; Frame.Checksum := Swap16(PWord(P)^); Result := True; end;

这段代码有几个地方值得停下来解释。

第一，PCardinal(P)^这个写法。P是PByte，PCardinal(P)把它强转成PCardinal，然后^解引用一次读出 4 个字节。这里其实已经是"按 4 字节读一个整数"了，之所以还要Swap32，纯粹是因为字节序相反。如果协议本来就是小端，这一句直接就是Frame.Timestamp := PCardinal(P)^，一行搞定。

第二，Len > Cardinal(PEnd - P)这个检查。PEnd - P是指针相减，得到的是两个地址之间相差的元素个数，因为基类型是Byte，所以就是字节数。这个检查挡住了绝大多数的越界读——攻击者或者线路噪声给你一个PayloadLen = $FFFFFFFF，不做检查的话Move直接访问一片非法内存。

第三，SetLength(Frame.Payload, Len)之后立刻Move。这里有一个隐含前提：Len不能大到让SetLength抛出EOutOfMemory。在实际工程里我一般会再加一个上限判断，比如if Len > 1024 * 1024 then Exit，避免一条畸形报文把内存吃光。

5.3 对齐和 packed 的取舍

前面提到了packed record。普通record会按字段的自然对齐补填充字节，比如：

type TBadRecord = record B: Byte; // 偏移 0 I: Integer; // 偏移 4（中间补了 3 个字节） end;

SizeOf(TBadRecord)是 8 而不是 5。如果你拿它去映射一段连续 5 字节的报文，字段全错位。加packed就变成紧凑布局，SizeOf回到 5。

但packed record有代价：非对齐地址的访问在某些架构上会变慢甚至报错。x86/x64 上容忍度很高，性能影响也很小，所以桌面场景基本可以放心用。真要在意，就还是走PByte逐字段读，完全绕开对齐问题——这也是我在解析代码里最终选择PByte的原因之一。

另外还有一个编译指令值得一提：

{$A8} // 记录字段按 8 字节对齐 {$A-} // 紧凑对齐（等价于 packed）

{$A-}的作用域是整个单元或到下一个{$A}为止，影响面很大，我一般不用，宁可给个别记录加packed，精确控制范围。

5.4 大小端处理不能想当然

我见过太多"只在开发机上测试通过"的代码，问题就出在字节序上。判断方法很简单：协议文档说清楚了字节序，就照着实现；没说清楚，就用抓包工具看一眼实际字节。

一个方便的自检手段：

var W: Word; P: PByte; begin W := $1234; P := @W; if P^ = $34 then Writeln('本机小端') else Writeln('本机大端'); end;

在 x86/x64 上永远是输出"本机小端"。所以凡是网络字节序（大端）的协议，读进来一律要Swap，写出去也一样。上面那个Swap32我用位运算手写而不是调Winapi.Winsock2里的htonl，原因是手写的不依赖特定单元，跨平台编译不会出问题。

6. 那些看着像指针、其实不是一回事的东西

6.1 对象引用本质是指针，但别当指针用

Delphi 里TObject的变量其实就是一个指针，指向堆上的对象实例。你可以做这种转换：

var Obj: TObject; P: Pointer; begin Obj := TStringList.Create; try P := Pointer(Obj); // 拿到对象地址 Writeln(TObject(P).ClassName);// 转回来还能用 finally Obj.Free; end; end;

能转，但别把它当成"省一次变量"的手段。对象引用的强转绕过了一切类型检查，你把一个TButton的地址转成TStringList再去用，编译器一声不吭，运行时就是灾难。真正需要这种转换的场合很少，基本是框架层的消息传递或者TList里存对象，而这些场景现在有泛型容器<T>可以替代，没必要自己玩火。

6.2 方法指针和事件背后的两个字段

procedure of object这个类型，很多人天天用（OnClick就是它），但不知道它内部是两个指针：

type TMethod = record Code: Pointer; // 方法代码地址 Data: Pointer; // 对象实例地址（Self） end;

也就是说，一个事件变量占 16 字节（64 位下），不是 8 字节。这一点在把事件存进TList或者做比较时会有影响——你不能简单地用=比较两个事件是否相同（其实可以，Delphi 支持，但要注意Data也要一致）。

更实际的影响是：事件赋值会隐式捕获对象的Self。如果你把一个窗体 A 的方法赋给窗体 B 的事件，然后 A 被释放了，B 触发事件时就会访问到一个已销毁的对象。这个坑在 MDI 或者多窗口项目里非常常见，报错信息通常是Access violation加一个奇怪的地址。解决办法是在A销毁前把B.OnSomething := nil，或者用一个中间层做转发。

6.3 absolute 关键字：省事但危险

absolute能让一个变量共享另一块内存，写法是：

var I: Integer; B: Byte absolute I; // B 和 I 共享低字节 begin I := $1234; Writeln(IntToHex(B, 2)); // 输出 34（小端） end;

这在做位操作、联合体解析的时候很方便，等价于 C 语言的union。但它比packed record更"隐形"——你看到一个变量声明，完全不知道它背后还挂着别人。我在维护代码时最怕看到absolute藏在几百行之外的声明区，因为改上面那个变量会影响下面这个，而调用链上毫无提示。

我的原则：absolute只在同一个函数内的极小范围内用，全局和类字段里一律禁止。要表达联合体，用带变体部分的record，至少类型信息是显式的。

7. 指针出问题时怎么查

7.1 调试器里直接看内存

指针问题的第一手信息在 CPU 窗口和 Memory 窗口。IDE 里调试到断点后，View菜单里能打开这两块。在 Memory 窗口输入地址，就能看到十六进制字节，配合PByte走位非常直观。

更实用的是 Watch 窗口里加表达式。假设你有P: PByte，直接 WatchP^就能看到当前字节，WatchPByte(NativeUInt(P) + 4)^能看到往后 4 个字节。这种写法比在代码里插Writeln快得多，而且不污染代码。

还有一个我常用的技巧：在 Watch 里写IntToHex(Cardinal(P), 8)看地址值，然后在 Memory 窗口里贴进去。地址为nil（也就是 0）的时候，Watch 里会显示 0，而访问P^立刻抛访问违例——这是判断"指针是不是空"最快的方式。

7.2 崩溃地址怎么反推

访问违例的报错信息里有两个地址，一个是出错指令地址，一个是访问的目标地址。目标地址是 0 或者00000010这类小数值，基本可以断定是空指针访问或者访问了已释放对象的字段（偏移 16 字节正好是某个字段）。

如果目标地址是一个大数值（比如$3F8A21C0），那更可能是野指针——指针变量本身存的是垃圾值，或者指向的内存已经被回收。这时候要在 Debug 版的Map文件里找指令地址对应的函数，基本能定位到哪一行。

在项目选项里打开Linker页的Map file生成详细映射，配合Detailed级别，能把崩溃地址精确对到函数甚至行号。这个配置建议所有需要长期维护的项目都打开。

7.3 打开范围检查，让错误早暴露

三个编译指令，开发阶段全部打开：

{$R+} // 范围检查：数组下标、子界越界 {$Q+} // 溢出检查：整数运算溢出 {$T+} // 类型化地址：@ 返回类型化指针

{$R+}对指针没有直接保护作用（指针不做下标检查），但对数组访问有保护，而指针操作经常和数组交织在一起，所以它仍然是值得打开的。{$Q+}在计算长度、偏移的时候能挡住溢出导致的负数下标。{$T+}前面讲过了，挡住类型错配。

正式发布版本里这些可以关掉（性能考虑），但一定要有一个Debug配置全程打开。我见过项目为了"发布版和调试版行为一致"而全程关闭这些检查，结果错误只能靠崩溃日志反推，效率差了一个数量级。

8. 几个我实打实踩过的指针坑

8.1 动态数组取址后的悬空问题

动态数组在 Delphi 里是引用计数的。取址这件事本身没问题，问题在于取址之后数组变量没了：

function GetDataPtr: PByte; var Arr: TBytes; begin SetLength(Arr, 100); FillChar(Arr[0], 100, $FF); Result := @Arr[0]; // 函数一返回，引用计数归零，内存释放 end;

这个和字符串那个坑是同一个根源。解决办法是把数组的所有权交给调用方，用out参数传出去，或者干脆返回TBytes让引用计数自己管。

还有一种更隐蔽的情况：数组还在，但在使用指针的过程中被SetLength扩容了。

var Arr: TBytes; P: PByte; begin SetLength(Arr, 10); P := @Arr[0]; SetLength(Arr, 1000); // 可能重新分配，P 失效 P^ := 1; // 未定义行为 end;

规则很简单：取址之后到用完之前，不要对数组做任何改变长度的操作。如果确实需要，用完再取一次。

8.2 ScanLine 的性能陷阱

处理位图的时候，TBitmap.ScanLine[Y]返回的是Pointer，指向第 Y 行的起始字节。用它可以做像素级操作，但有几个前提。

第一，必须先设置PixelFormat。默认的位图可能是pfDevice，每像素字节数随显示器变，用ScanLine算出来的偏移完全不可控。正确做法是先设成pf32bit或pf24bit。

第二，行与行之间的实际字节数（Stride）不等于Width * BytesPerPixel。位图每行末尾会对齐到 4 字节边界，pf24bit且宽度是奇数的时候，每行末尾有 1 字节填充。如果你按Width * 3步进，第二行开始就错位了。

var Bmp: TBitmap; Row: PByte; X, Y: Integer; BytesPerPixel: Integer; begin Bmp := TBitmap.Create; try Bmp.PixelFormat := pf32bit; Bmp.Width := 101; Bmp.Height := 100; BytesPerPixel := 4; for Y := 0 to Bmp.Height - 1 do begin Row := Bmp.ScanLine[Y]; for X := 0 to Bmp.Width - 1 do begin // 直接写 BGRA 四个字节 Row[X * BytesPerPixel + 0] := 0; // B Row[X * BytesPerPixel + 1] := 0; // G Row[X * BytesPerPixel + 2] := 0; // R Row[X * BytesPerPixel + 3] := 255; // A end; end; finally Bmp.Free; end; end;

第三，ScanLine返回的指针只在位图未被修改前有效。如果你在位图处理过程中调用了Canvas.Draw或者Bmp.Width :=之类的操作，内部可能重新分配缓冲区，之前拿到的指针就废了。所以模式应该是：一次性取行指针，循环处理完，再统一刷新，别在循环里反复调ScanLine之外的操作。

8.3 局部指针变量不初始化

这个错误低级但高频：

procedure Test; var P: PInteger; begin if SomeCondition then P := @GlobalValue; P^ := 10; // SomeCondition 为 False 时，P 是随机值 end;

Delphi 的局部变量不会自动初始化成nil（除了托管类型），指针变量的值就是栈上残留的垃圾。一旦条件分支漏了赋值，P^ := 10就往一个随机地址写数据，后果可能是静默的数据损坏，也可能是立刻崩溃。

我的习惯是所有指针局部变量在声明块里显式P := nil;，然后在解引用前加if P <> nil判断。虽然多写一行，但换来的是崩溃时能一眼看出"这是空指针"，而不是去追一个随机地址。

同样的道理，类字段的指针、记录里的指针字段，在构造函数或New之后也要立刻置nil，否则FreeMem一个野指针就是内存管理器的直接崩溃。

指针这套东西，说到底就是一句话：编译器把"这块内存归你管"的责任交给你了。规则不多——类型化优先、成对分配释放、取址后别让源消失、解引用前先判空——但每一条都是硬规则。我在实际项目里用得最多的这几种写法：解析协议用PByte游标走位、位图处理用ScanLine配手动步长、和外部接口交互时用GetMem/FreeMem配显式长度、字符串一律用string只在调 API 的瞬间转PChar。这套约定用了几年，指针相关的崩溃从"每月几次"降到了"基本没有"。如果你手上也有那种满是@和P^的老代码，别急着重写，先把上面这些规则对照着过一遍，多半能找出几处正在等着崩的地方。