这是典型的不可见字符污染，如零宽空格（\u200b）、bom头（\ufeff）等导致sql解析失败；需通过纯文本中转、显示不可见字符、正则清洗或专用工具清除。

sql复制粘贴后报错：error: syntax error at or near "" 或乱码关键字

这是典型的不可见字符污染，比如从网页、notion、企业微信、飞书或带格式的pdf里直接复制sql，会混入零宽空格（\u200b）、左至右标记（\u200e）、软连字符（\u00ad）甚至全角空格（　）。postgresql/mysql/sqlite 一碰到这些就直接报语法错误，且错误位置往往不提示具体字符，只显示“near”后面一堆乱码。

实操建议：

• 粘贴前先扔进纯文本中转站：用系统自带的「记事本」（Windows）或「TextEdit → 纯文本模式」（macOS），再复制出来——它会自动剥离所有富文本元信息
• 编辑器里开启“显示不可见字符”：VS Code 按 Ctrl+Shift+P 输入 Toggle Render Whitespace；Sublime Text 开启 View → Show Whitespaces
• 终端执行前加一层过滤：Linux/macOS 下可用 pbpaste | tr -cd '\11\12\15\40-\176' | pbcopy（清理剪贴板中的非ASCII可打印字符）

MySQL客户端执行时报Unknown command但SQL明明是合法的

常见于从网页文档复制的 SELECT * FROM users;，表面看没问题，实际末尾藏了零宽空格或BOM头。MySQL CLI 对输入极其敏感，遇到非标准空白就会把整行当 shell 命令解析，于是报这个误导性错误。

实操建议：

• 别在 MySQL CLI 里直接粘贴长SQL——改用 source 命令加载文件：source /tmp/query.sql，文件内容必须是 UTF-8 无 BOM
• 生成SQL文件时用命令行工具清洗：echo "SELECT * FROM t;" | iconv -f utf8 -t ascii//ignore | sed 's/[^[:print:]]//g' > clean.sql
• 如果必须粘贴，先在终端里运行 cat -v 查看真实字符：cat -v 回车后粘贴，你会看到 ^@、M-bM-^@M-^ 这类标记，说明有非法编码

Python用sqlite3执行复制来的SQL总抛sqlite3.OperationalError: near "?": syntax error

问题不在占位符本身，而在于 SQL 字符串开头或结尾混入了不可见控制字符（比如 \ufeff BOM），导致 sqlite3 解析器第一眼就卡住。哪怕只多一个 \u200c（零宽非连接符），也会让整个语句失效。

实操建议：

• 加载SQL前强制标准化：sql.strip().replace('\u200b', '').replace('\ufeff', '').replace('\u200e', '')
• 用正则预清洗（更彻底）：re.sub(r'[\x00-\x08\x0b\x0c\x0e-\x1f\x7f-\x9f\u200b-\u200f\u202a-\u202e]', '', sql)
• 开发阶段加个防护钩子：在 cursor.execute() 前插入检查逻辑，打印 repr(sql[:50])，一眼看出异常前缀

为什么有些编辑器（如 DBeaver）能“自动修复”，而 VS Code + SQLite 插件不行

根本区别在于是否启用“粘贴时自动清理”。DBeaver 默认开启 Remove invisible characters on paste，而 VS Code 的大多数数据库插件（包括 SQLTools）默认不处理，它把粘贴行为完全交给编辑器底层，而编辑器只管换行和缩进，不管 Unicode 控制符。

实操建议：

• VS Code 用户装扩展 Remove Invisible Characters，启用后粘贴自动过滤
• 或者在 settings.json 里加："editor.suggest.snippetsPreventQuickSuggestions": false 不起作用，真正有效的是配置 "editor.formatOnPaste": true 配合 Prettier 或自定义脚本
• 最稳方案：写个一键清洗函数，绑定到快捷键，比依赖编辑器行为更可控

真正的麻烦点不是“怎么删字符”，而是这些字符在常规编辑器里完全不可见，连 len() 和 print() 都看不出异样，得靠 repr() 或十六进制查看器才能定位。一旦漏掉一个，就可能让整条SQL静默失败。