Delphi中TFileStream.Create参数使用or与+的区别是什么？

核心差异的本质 #

TFileStream构造函数的模式参数本质是位掩码，这类常量（比如fmOpenRead、fmShareDenyNone）的设计逻辑是：每个常量对应二进制里唯一的1位，不会有重叠。

• 当组合两个无重叠位的常量时，or和+的数值结果确实一致，比如你测试的1 or 16和1+16都等于17——因为两个数的二进制位没有重叠，相加不会产生进位，和位运算的结果相同。
• 但一旦遇到重复设置同一个标志或者位有重叠的常量，两者的差异就会立刻显现：
  • 1 or 1结果还是1（位运算只会把该位设为1，重复操作不改变结果）
  • 1+1结果是2（数值相加产生进位，改变了二进制位结构）
  • 再比如2 or 6，2是二进制0010，6是0110，or后保留所有为1的位，结果是0110（6）；而2+6=8（二进制1000），这已经是完全不同的位掩码了。

为什么必须用or #

Windows底层的文件操作API（TFileStream最终会调用这类API）只认位是否被设置，而不是数值大小：

1. 避免错误的位污染：如果用+重复添加同一个标志，会导致数值进位，改变其他位的值，API会识别出错误的模式。比如fmOpenRead + fmOpenRead得到的数值2，对应的是fmOpenWrite的标志，完全偏离了原本只读的意图。
2. 符合设计规范：位掩码参数的标准写法就是用or组合，这是所有底层API约定俗成的用法，懂位掩码的开发者一眼就能理解代码逻辑。
3. 容错性更高：即使不小心重复写了同一个标志，or操作不会产生任何错误，结果依然正确；而+会直接破坏参数的正确性。

原理依据 #

这类文件模式常量的设计遵循Windows API的位掩码规则：每个选项对应DWORD类型中的单独一位，通过位运算组合来表示多个选项同时生效。Delphi的fm系列常量直接映射了Windows的GENERIC_*、FILE_SHARE_*等宏定义，这些宏本身就是为位运算设计的。

内容的提问来源于stack exchange，提问作者user1937012