$匹配行尾位置而非字符，是否匹配每行末尾取决于多行模式m：默认只匹配整个字符串末尾，启用m后可匹配每个换行符前的位置，并兼容多种换行符格式。
正则表达式中 $ 匹配行尾的逻辑，核心在于“它匹配的是位置，不是字符”，而这个位置是否生效、在哪生效，取决于是否启用多行模式（m 标志）以及目标文本中的换行符类型。
默认模式下：$ 只认整个字符串末尾
没加 m 时，$ 只匹配整个输入字符串的最末端（不包括末尾换行符之后的位置）。哪怕字符串里有多个 \n，中间的换行符前后都不会被 $ 视为“行尾”。
-
/abc$/.test("abc")→ true -
/abc$/.test("abc\nxyz")→ false（整个字符串不以 abc 结尾） -
/abc$/.test("abc\n")→ false（$停在\n前，但这里\n是结尾，所以 abc 后面还有字符）
多行模式（m 标志）下：$ 按换行符切分后匹配每行末尾
加上 m 后，引擎会把字符串按 \n、\r\n、\r、\u2028、\u2029 划分成多行，$ 就能在每行末尾（即每个换行符之前）匹配一次。
-
/abc$/m.test("def\nabc\nxyz")→ true（第二行以 abc 结尾） -
/$/.exec("abc\n")→ 返回 index: 3（匹配在\n前，不是匹配\n本身） -
/abc\n$/.test("abc\n")→ false（$在\n前，\n是独立字符，不能和$连写成\n$来匹配）
不同平台换行符导致的实际差异
Windows 用 \r\n，Linux/macOS 用 \n。如果正则只写 $ 且启用了 m，它能识别所有标准换行符；但若代码环境或数据源混用换行格式（比如从 Windows 复制文本到 Linux 环境处理），可能因 \r 未被正确解析而漏匹配。
- C# 示例中
$不生效，常因原始字符串含\r\n，而$默认停在\n前，\r成为“行尾后残留字符”，需显式写\r?$或\r?\n$ - 更稳妥写法：
/abc(?=\r?\n|$)/—— 用先行断言避开对换行符本身的依赖 - 避免硬编码：
/abc\s*$/m可兼容末尾空白或换行，但要注意\s也匹配\r、\t等
JavaScript 的限制与绕过方式
JS 不支持 \Z（绝对字符串结尾，允许末尾一个换行符），也不支持 \A。这意味着无法用原生锚点精确区分“整串结尾”和“最后一行结尾”。
- 想严格匹配整串结尾？用
str.endsWith("abc")或^abc$（无m） - 想确保某模式出现在最后一行？先
split('\n').pop()再匹配，或用/abc(?=(?:\r?\n)?$)/ - 处理用户粘贴文本时，建议先统一换行符：
text.replace(/\r\n/g, '\n').replace(/\r/g, '\n')
