windows下需通过pc/sc接口（scardestablishcontext等）与nfc读卡器通信，指定scard_protocol_tcl协议，避免scard_e_proto_mismatch错误；linux需卸载hid_generic驱动以释放usb设备；macos需处理dylib签名与rpath问题；uid为大端原始字节流，须逐字节hex格式化。
Windows下用Winscard.dll读取ISO14443-A卡（如MIFARE Classic）
绝大多数USB NFC读卡器在Windows上走的是PC/SC协议栈，C++不直接和硬件打交道，而是通过SCardEstablishContext、SCardConnect、SCardTransmit这一套标准接口通信。别想着用libusb或串口指令——除非你用的是开发板级模块（如PN532 UART模式），否则Windows驱动层已经把底层封装掉了。
常见错误现象：SCardTransmit返回0x80100016（SCARD_E_PROTO_MISMATCH），说明ATR协商失败，通常是因为没正确指定dwPreferredProtocols；或者SCardListReaders返回空列表，其实是服务没开（scardsvr服务需手动启动）。
- 先调用
SCardEstablishContext(SCARD_SCOPE_SYSTEM, nullptr, nullptr, &hContext)，不能传SCARD_SCOPE_USER，否则部分读卡器不可见 -
SCardConnect时dwShareMode必须是SCARD_SHARE_SHARED（只读卡），SCARD_SHARE_EXCLUSIVE常被其他程序占用导致失败 - 发送APDU前务必确认协议：MIFARE Classic通常用
SCARD_PROTOCOL_TCL（T=CL），不是T0或T1；可用SCardStatus查当前协议 - 典型Select命令：
{0x00, 0xA4, 0x04, 0x00, 0x07, 0xD2, 0x76, 0x00, 0x00, 0x85, 0x01, 0x01}（选MIFARE Ultralight），注意长度字段要自己算，SCardTransmit不帮你补
Linux下用libnfc识别NTAG213/215时卡在nfc_initiator_select_passive_target
libnfc默认用pn532_uart或acr122_usb后端，但很多廉价读卡器实际是ACR122U的变种，却报Unable to claim USB interface。这不是权限问题，而是内核hid-generic驱动抢了设备句柄——得先卸载它。
使用场景：树莓派+USB NFC读卡器做门禁记录，要求低延迟、支持防冲突（多卡同时靠近）。
立即学习“C++免费学习笔记（深入）”；
- 执行
sudo modprobe -r hid_generic usbhid再插拔设备，然后lsusb -v | grep -A 2 "bInterfaceClass.*ff"确认接口类变成0xff（厂商自定义），而非0x03（HID） -
nfc_initiator_select_passive_target超时常见于天线未校准：运行nfc-list看是否有ACR122U字样，没有就说明驱动没加载成功 - NTAG213的UID是7字节，但
nfc_target_info_t里nti.nai.abtUid只暴露前4字节；要全UID得用nfc_initiator_transceive_bytes发0x00 0x30 0x00读块0 - 性能影响：设
MAX_TARGETS = 1能加快单卡响应，但会丢弃多卡场景下的第二张卡；防冲突必须留默认值
macOS无法加载libnfc动态库，报错dyld: Library not loaded: libnfc.6.dylib
macOS的libnfc依赖链很脆，Homebrew装的版本默认链接到/usr/local/lib，但运行时找不到——因为系统不允许从该路径加载未签名动态库（Gatekeeper限制），不是路径没加对。
根本原因：Apple从macOS 10.15开始强制hardened runtime，任何dlopen加载的dylib必须带com.apple.security.cs.allow-dylibs entitlement，而libnfc没这个签名。
- 临时方案：编译时加
-Wl,-rpath,@executable_path/../Frameworks，把libnfc.6.dylib拖进Xcode项目Frameworks目录，并勾选“Copy items if needed” - 更稳的做法：用
otool -L your_binary确认链接路径，再用install_name_tool -change "libnfc.6.dylib" "@rpath/libnfc.6.dylib" your_binary重写依赖 - 别用
sudo ln -s硬链到/usr/lib，macOS SIP会阻止，且新版系统直接报错 - 兼容性注意：libnfc 1.7.1以上才支持macOS 12+的ARM64架构，旧版编译会静默失败
C++里处理NFC UID时字节序和编码容易搞反
NFC卡片的UID是物理层原始字节流，不是字符串。有人把abtUid[0..3]直接当ASCII打印，结果看到乱码；还有人用std::stoi转十六进制字符串，却忘了高位在前（big-endian），导致UID倒着解析。
例如MIFARE Classic 1K的4字节UID 0x12 0x34 0x56 0x78，正确HEX字符串是"12345678"，不是"78563412"。
- 安全做法：用
std::ostringstream逐字节格式化：oss - 别用
std::string(reinterpret_cast<const char>(abtUid), len)</const>构造字符串——UID含0x00，会截断 - Android手机模拟的NFC卡（HCE）返回UID是随机生成的，每次不同；真卡UID固化在ROM里，可放心用于唯一标识
- NTAG216的UID是7字节，但前2字节固定为
0x04+ 制造商ID，真正序列号从第3字节开始——别全当成ID用
真正麻烦的不是调不通，是调通了但UID解析错、协议选错、权限漏掉，结果在现场跑几天才发现数据对不上。尤其Windows服务状态、macOS签名、Linux内核模块这三处，出问题时日志里几乎不报具体原因。
