应隐藏迭代器内部实现细节：禁止暴露裸指针、哨兵节点、随机访问标签及地址比较逻辑，仅提供最小必要接口（如 operator*、++、!=），所有字段设为 private，杜绝 get_ptr() 等泄露接口。
返回迭代器可能暴露容器节点指针或内存布局
直接返回 iterator（尤其是自定义容器的嵌套迭代器）时，如果迭代器内部持有裸指针（如 Node* 或 T*），调用方就能通过解引用、取地址、甚至强制转型窥探底层结构。比如一个链表容器的 iterator 若公开其 p 成员（Link* p），外部代码就能访问 p->next、p->data，等于把链表节点的字段全摊开——这违反了封装原则，也使容器无法在不破坏 ABI 的前提下更换实现（比如从单链表改成跳表）。
end() 返回值泄露哨兵节点或空指针语义
end() 本应只用于比较，但若其实现是返回 nullptr 或指向某个固定哨兵节点的指针，外部就可能误用：*(c.end()) 导致未定义行为，或通过 static_cast 反推容器是否使用环形链表/哨兵节点等细节。更隐蔽的是，某些实现让 end() 指向“末节点后一位置”的真实内存（如 &last_node.next），这会暴露分配策略（是否预留尾部空间）和节点大小。
迭代器类型暴露容器随机访问能力
当容器对外声明其迭代器为 std::random_access_iterator_tag，等于明示支持 it + n、it1 - it2 等操作——这反向约束了内部必须是连续内存（如 vector）或可计算偏移的结构（如 deque）。一旦后续想换成哈希表或红黑树，就必须改迭代器类别，而所有依赖随机访问语义的用户代码（比如用 std::sort 或二分查找）会直接编译失败或逻辑错误。
operator== 和 operator!= 的实现暗示遍历机制
若两个迭代器比较仅靠指针相等（p == other.p），说明是基于地址的遍历；若还需比对容器对象身份（this->container == other.container），则暴露了“迭代器绑定容器实例”的设计；更麻烦的是，某些手写迭代器用计数器模拟位置（index），此时 it1 == it2 实际比较的是数值而非地址——这会让用户误以为该容器支持 O(1) 随机跳转，而实际可能是 O(n) 遍历模拟。
立即学习“C++免费学习笔记（深入）”；
真正安全的做法是：迭代器只暴露最小必要接口（operator*、operator++、operator!=），所有内部字段设为 private，且不提供任何获取原始指针的成员函数（如 get_ptr()）。哪怕性能稍差，也比把内存布局、节点结构、分配策略全钉在 ABI 上强。
