_str.contains() 默认按正则匹配，含元字符会误解析；需字面匹配时必须设 regex=False 和 na=False，并注意大小写与空值处理。
为什么 _str.contains('abc') 有时不匹配明明存在的数据
默认情况下，_str.contains() 把输入当正则表达式处理，而 a、b、c 虽然本身不是元字符，但一旦你写 'a.c' 或 'ab?c' 就会意外触发正则逻辑，导致匹配失败或误匹配。更常见的是字符串里有 .、+、*、?、[、^、$ 这类字符，直接传进去会被解释成正则语法，而不是字面意思。
实操建议：
- 如果只是想查纯文本子串（比如找包含 "user_id=123" 的日志），务必加参数
regex=False：df[df['log'].str.contains('user_id=123', regex=False)] - 如果真要用正则（比如匹配邮箱、手机号），必须确认字符串已转义或用原始字符串：用
r'd{3}-d{4}'而不是'\d{3}-\d{4}' - 空值（
NaN）默认返回NaN，导致布尔索引出错；加na=False更安全：.str.contains('abc', regex=False, na=False)
_str.contains() 的 case 和 na 参数怎么选
大小写敏感是默认行为，但业务数据常混用大小写，比如搜索 "ERROR" 却漏掉 "error" 或 "Error"。这时候不设 case=False 就会丢行。
空值处理更隐蔽：Pandas 对 NaN 做布尔运算时返回 NaN，而 df[condition] 会把 NaN 当作 False 吗？不会——它直接让整行被过滤掉（取决于上下文），但更稳妥的做法是明确控制。
-
case=False等价于底层调用str.lower()再匹配，性能略低，但对用户友好；若列很长且确定大小写统一，可省略 -
na=False表示把所有空值视为False；na=True视为True；不传则保留NaN，在布尔索引中可能引发Boolean Series key will be reindexed类警告 - 组合常用写法：
df['col'].str.contains('abc', case=False, regex=False, na=False)
用正则时，^、$、
因为 _str.contains() 本质是检查“是否在字符串中出现”，它等价于 re.search(pattern, string)，不是 re.match()。所以 ^abc 并不是“以 abc 开头”，而是“从任意位置开始能匹配到一个以 abc 开头的子串”——这几乎总为真；同理 abc$ 也不代表“以 abc 结尾”，而是“存在某个位置，后面紧跟着 abc 且那是字符串末尾”，语义容易绕晕。
- 要真正匹配开头，用
str.startswith('abc')，快且语义清晰 - 要匹配结尾，用
str.endswith('xyz') - 要单词边界（如只匹配独立的 "cat" 而非 "scatter" 中的 cat），必须用
regex=True并写r'cat'，且确保regex=True（默认就是 True，但显式写出更防错） - 性能提示：正则边界符本身不慢，但
在 Unicode 字符串中行为复杂，中文文本慎用；英文场景下没问题
匹配中文、emoji 或特殊符号时要注意什么
中文和 emoji 不是问题本身，问题是它们常和正则元字符共存，或者被错误地当成字节处理。比如 '你好+' 中的 + 会被当量词，'⚠️abc' 中的 emoji 是合法 Unicode 字符，但某些旧版 Pandas 对 surrogate pair 支持不稳定。
- 含特殊符号的字面匹配，坚持
regex=False最省心 - 必须用正则匹配中文时，避免用
.（它不一定匹配中文），改用[u4e00-u9fa5]或[wu4e00-u9fa5]显式声明范围 - Pandas 1.3+ 对 emoji 支持较好，但若遇到
UnicodeDecodeError或匹配异常，先检查列 dtype 是否为object（不是string）；用df['col'] = df['col'].astype('string')可提升一致性 - 不确定编码时，先试
df['col'].str.encode('utf-8').str.contains(...)—— 但这是下策，优先保证源头数据编码干净
regex=False 和 na=False 这两个开关——它们不显眼，但一漏就查半天。 
