Rust is an emerging programming language with superior security reliability. Its safety is guaranteed by both sophisticated validations in compile time and comprehensive safety checks at runtime. Beyond safety mechanisms, Rust provides a critical keyword \texttt{unsafe}, allowing users to perform more efficient low-level memory operations while bypassing partial safety constraints. In practice, Rust provides many standard library APIs as safe/unsafe counterparts that share the same underlying safety conditions. The safe versions include runtime safety checks to ensure that arguments satisfy the required safety conditions, while the unsafe versions invoke unsafe primitives and rely on external safety guarantees. Therefore, unsafe implementations are more flexible, but also introduce greater safety risks. We compare the behavioral differences between all paired safe/unsafe counterpart implementations in the Rust standard library, and abstract their safety conditions. According to their requirements, the safety conditions of some safe API calls in real programs may already guaranteed to hold, making the corresponding runtime checks redundant. In this paper, we propose an approach based on abstract interpretation to efficiently detect such safe APIs calls and replace them with their unsafe counterparts to eliminate redundant runtime checks. The proposed approach is evaluated on real-world Rust crates, comparing performance before and after the safe-to-unsafe replacements. Experimental results indicate that after the safe replacement of all identified program sites, the substituted operators can achieve speedups of up to $36$%.