这个坑值得记一笔。Milvus 2.4 用 alias kb 指向集合 kb_v1，重建 kb_v2 后 alter alias 指过去，查询仍返回旧数据，重启客户端才生效。
刚开始盯着「一致性级别导致读到的还是旧快照」，折腾了半个多小时，排掉了。
真正麻烦的地方在于，几个原因的现象几乎一样。客户端缓存了集合的 schema 和路由信息；alias 变更后旧连接没有刷新；代码里直接写了物理集合名，没走 alias。
上来先看 alias 当前指向哪个集合
python -c "from pymilvus import connections,utility;print(utility.list_aliases(collection_name='kb'))"再往下重建连接后再查一次数据量做对比
python -c "from pymilvus import connections;connections.disconnect('default');connections.connect('default', host='milvus', port='19530')"然后确认查询走的是 alias 而不是物理名
python -c "print(client.query(collection_name='kb', filter='id > 0', limit=1))"剩下的就是切换后立即校验两个集合的条数差异
python check_count.py --alias kb --expect kb_v2命令输出我都留了记录，免得改完记不清原来的值。
怎么算真的好了，看的是同一批现象。查询返回新集合的数据，alias 列表指向 kb_v2，重启前后结果一致。
alias 是服务端的软链接，客户端缓存却可能保留旧路由，切换动作要配套一次连接重建，最好在发布流程里固定下来。这类问题最好一次改到位，反复小改反而容易把原因搅混。