我之前也踩过这个坑！chrono的弃用提示确实有点误导人——with_ymd_and_hms只支持秒级精度，完全满足不了毫秒需求。别担心，有两个非常靠谱的非弃用方案，都是贴合官方设计思路的：

方案一：先构造NaiveDateTime再转换（最适合从日期时间字段构造） #

这是chrono官方现在主推的思路：先分别构造日期和时间的无时区基础类型（Naive系列），组合成NaiveDateTime后，再绑定UTC时区得到DateTime<Utc>。这种方式完全避开了弃用方法，还能完美支持毫秒精度：

use chrono::{Utc, NaiveDate, NaiveDateTime};

// 假设你有这些输入字段
let year = 2024;
let mon = 5;
let day = 20;
let hour = 14;
let mins = 30;
let secs = 45;
let millisecs = 123;

// 1. 构造NaiveDate（如果确定日期合法，可用from_ymd，否则用from_ymd_opt做错误处理）
let naive_date = NaiveDate::from_ymd(year, mon, day);
// 2. 构造带毫秒的NaiveTime
let naive_time = NaiveTime::from_hms_milli_opt(hour, mins, secs, millisecs)
    .expect("Invalid time components");
// 3. 组合成NaiveDateTime
let naive_dt = NaiveDateTime::new(naive_date, naive_time);
// 4. 绑定UTC时区得到最终的DateTime<Utc>
let time = Utc.from_utc_datetime(&naive_dt);

如果你的输入可能存在非法值（比如2月30日、25点这种），建议用_opt方法配合match做错误处理，避免panic：

use chrono::{Utc, NaiveDate, NaiveDateTime};

let year = 2024;
let mon = 5;
let day = 20;
let hour = 14;
let mins = 30;
let secs = 45;
let millisecs = 123;

match NaiveDate::from_ymd_opt(year, mon, day) {
    Some(naive_date) => {
        match NaiveTime::from_hms_milli_opt(hour, mins, secs, millisecs) {
            Some(naive_time) => {
                let naive_dt = NaiveDateTime::new(naive_date, naive_time);
                let time = Utc.from_utc_datetime(&naive_dt);
                // 处理合法的DateTime
            }
            None => eprintln!("Invalid time components (e.g. 25 hours, 61 minutes)"),
        }
    }
    None => eprintln!("Invalid date components (e.g. February 30th)"),
}

方案二：用毫秒级时间戳直接构造（适合已有时间戳的场景） #

如果你的输入是从1970-01-01 00:00:00 UTC开始的毫秒数，可以直接用timestamp_millis_opt一步到位，这个方法也是完全非弃用的：

use chrono::Utc;

let timestamp_millis = 1716196245123; // 对应2024-05-20 14:30:45.123 UTC

match Utc.timestamp_millis_opt(timestamp_millis) {
    Ok(time) => {
        // 处理合法的DateTime
    }
    Err(e) => eprintln!("Invalid timestamp: {}", e),
}

为什么原来的方法被弃用？ #

chrono官方的设计思路是把「日期构造」和「时间构造」拆分开，原来的ymd_opt+and_hms_milli_opt是把时区绑定和日期时间构造混在一起，现在推荐先构造无时区的基础类型（Naive系列），再绑定时区，这样代码逻辑更清晰，也更符合类型设计的初衷。

最佳实践总结 #

• 如果是从单独的年、月、日、时、分、秒、毫秒字段构造：优先用方案一，这是最贴合官方当前设计的写法，可读性和可维护性都更好。
• 如果已经有毫秒级时间戳：直接用方案二的timestamp_millis_opt，简单高效。
• 无论哪种方案，都要注意错误处理——如果输入可能非法，一定要用_opt方法配合match/if let，不要盲目unwrap，避免线上panic。