CMD命令 和 PowerShell命令 在修改文件时间方面的对比。我们将常见的文件时间修改操作（如创建时间、访问时间和修改时间）进行对比，并以表格形式展示两者的差异：

Get-Date (Microsoft.PowerShell.Utility) - PowerShell | Microsoft Learn

(get-date) - (get-ciminstance win32_operatingsystem).lastbootuptime

解释：

  • get-date：获取当前的日期和时间。
  • get-ciminstance win32_operatingsystem：获取操作系统的信息（通过 CIM）。返回的对象包含了多个属性，其中之一是 lastbootuptime，表示系统的上次启动时间。
  • 使用 () 将两者包围，表示先执行这两部分操作，然后进行相减，得出系统运行时间。

结果：

这条命令的作用是计算从上次启动到当前时间的时间差，得到系统的运行时长。

与 任务管理器 性能 CPU  正常运行时间 对应 PixPin_2025-09-19_02-10-01

PS C:\Users\Administrator> (get-date) - (get-ciminstance win32_operatingsystem).lastbootuptime

Get-Date (Microsoft.PowerShell.Utility) - PowerShell | Microsoft Learn
Days              : 0
Hours             : 1
Minutes           : 31
Seconds           : 13
Milliseconds      : 573
Ticks             : 54735730943
TotalDays         : 0.063351540443287
TotalHours        : 1.52043697063889
TotalMinutes      : 91.2262182383333
TotalSeconds      : 5473.5730943
TotalMilliseconds : 5473573.0943

  • 天数: 0
  • 小时: 1
  • 分钟: 31
  • 秒数: 13
  • 毫秒: 573
  • 刻度（Ticks）: 54735730943
  • 总天数: 0.063351540443287
  • 总小时数: 1.52043697063889
  • 总分钟数: 91.2262182383333
  • 总秒数: 5473.5730943
  • 总毫秒数: 5473573.0943

这些数值通常用于表示时间间隔，具体包括天、小时、分钟、秒、毫秒等单位的详细拆解。

PS C:\WINDOWS\system32> (get-date) - (get-ciminstance win32_operatingsystem).lastbootuptime


Days              : 1
Hours             : 8
Minutes           : 46
Seconds           : 7
Milliseconds      : 843
Ticks             : 1179678432900
TotalDays         : 1.36536855659722
TotalHours        : 32.7688453583333
TotalMinutes      : 1966.1307215
TotalSeconds      : 117967.84329
TotalMilliseconds : 117967843.29

这个命令的作用是计算 Windows系统的本次开机运行时长（Uptime）：左侧get-date获取当前系统时间，右侧从CIM类Win32_Operatingsystem中读取系统记录的本次启动时间LastBootUpTime，二者的差值就是系统开机至今的持续运行时间。

你贴出的输出对应的时间精度可以分为三类：

1. 底层最高精度：100纳秒级（10⁻⁷秒）

通过输出中的Ticks字段体现：

.NET框架的时间单位Tick定义为1 Tick = 100纳秒，你这里的Ticks值1179678432900换算后就是117967.84329秒，和TotalSeconds字段的值完全对应，是整个计算的最高可达到精度。

2. 默认展示精度：整毫秒级（10⁻³秒）

PowerShell默认会把时间差拆分为「天+时+分+秒+整毫秒」的组合格式，你看到的Milliseconds: 843就是只显示毫秒的整数部分，精度到1毫秒。

3. 累计项扩展精度：0.01毫秒级（10⁻⁵秒）

带Total前缀的累计字段会做单位转换，其中TotalMilliseconds可以展示不到1毫秒的剩余精度： 你这里的TotalMilliseconds: 117967843.29中，整数部分117967843对应117967秒整，小数部分.29是不到1毫秒的剩余精度（对应2900个Tick，即0.29毫秒），和默认显示的843毫秒相加刚好是843.29毫秒，和TotalSeconds的117967.84329完全吻合。

补充说明

这个精度的上限由系统记录的启动时间精度决定：

  • Windows 7及以上版本的LastBootUpTime属性默认记录到毫秒级，因此可以算出毫秒级的开机时长；
  • 更老的Windows版本（如XP）该属性可能只到秒级，就不会出现Milliseconds相关字段；
  • 如果需要精确到微秒级的运行时长统计，需要调用系统底层性能计数器APIQueryPerformanceCounter计算，因为LastBootUpTime本身没有微秒级的记录。

你可以通过执行(Get-Date).Ticks - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime.Ticks验证，返回值会和你输出里的Ticks值完全一致，说明精度是准确的。

为什么LastBootUpTime无法提供微秒级精度的运行时长统计，而必须依赖QueryPerformanceCounter (QPC)？ 这涉及到Windows内核时间管理的底层设计差异。以下是从硬件、内核实现和系统行为三个维度的深入解释：

一、LastBootUpTime的根本限制：它记录的不是“开机瞬间”

1. 什么是 LastBootUpTime？

  • 它来源于注册表键：
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows\ShutdownTime
    这是一个 FILETIME 结构（64位整数，单位：100纳秒间隔，基于1601年1月1日UTC）。
  • 但关键在于：这个值仅在系统正常关闭时被写入注册表，并在下次开机完成内核初始化后被读取回系统中（存放在Win32_OperatingSystem对象中）。

2. 为什么它无法精确到微秒？

因素 说明 对精度的影响
更新时机 仅在关闭时写入注册表，开机时才从注册表读取<br>→ 实际记录的是“上次关闭完成的时间”，不是“本次开机开始的时间” 引入关机/开机过程中的不确定性（如未清除缓存、延迟写磁盘）
写入延迟 注册表写入由内核事务管理器（KTM）处理，非实时同步<br>→ 可能因缓存刷新策略（如Lazy Write）导致实际写入滞后数十至数百毫秒 开机时间记录可能比真实开机瞬间迟到 10-500ms
语义模糊 系统考虑“开机完成”的标准是：用户会话服务（Winlogon）就绪，而非内核或HAL初始化完成<br>→ 实际测量点滞后于真正的硬件通电时刻（可能相差秒级） 无法捕获早期启动阶段（如POST、BIOS、引导加载程序执行时间）
存储精度 vs 实际意义 虽然FILETIME理论支持100ns精度，但该时间戳代表的是一个“人为定义的事件”（会话就绪），而非连续物理时钟事件<br>→ 即使存储精度高，其指向的事件本身就具有毫秒级以上的抖动（Jitter） 微秒级精度在此语境下毫无意义——就像用原子钟测量沙漏漏沙时间一样

✅ 结论：LastBootUpTime设计初衷是用于审计关机/开机事件（如追踪非正常关机），而非测量精确运行时长。它固有地丢失了开机瞬间的连续时间信息。

二、QueryPerformanceCounter如何实现微秒（甚至纳秒）级精度？

1. 底层硬件基础：CPU时间戳计数器（TSC）

  • 现代x86/x64 CPU内置不变时间戳计数器（Invariant TSC）：
    • 每个CPU核心有一个递增的64位寄存器，在每个CPU时钟周期自动加1（不受睡眠/频率缩放影响）。
    • 频率固定（例如：3.5 GHz CPU → 每tick约0.286纳秒）。
    • 极低开销：读取TSC仅需几十个CPU周期（~10-30ns），无需系统调用。

2. 内核封装：如何暴露TSC给应用？

Windows通过两层抽象提供高精度计时：

层级 机制 精度来源
硬件层 CPU TSC寄存器（或HPET/ACPI PM定时器作为后备） 由CPU主频决定（典型：0.1-1ns/cycle）
内核层 KeQueryPerformanceCounter() / KeQueryPerformanceFrequency()<br>（内部使用rdtsc指令读取TSC） 校准TSC频率以补偿跨核心漂移（现代CPU基本不变）
用户层 QueryPerformanceCounter() / QueryPerformanceFrequency()<br>（Win32 API，内转调内核函数） 返回校准后的TSC值及其频率

3. 计算流程（以微秒为例）

cpp
LARGE_INTEGER start, end, freq;
QueryPerformanceFrequency(&freq); // 获取计数器频率（Hz）
QueryPerformanceCounter(&start);  // 记录起始TSC值
// ... 执行需测量的代码 ...
QueryPerformanceCounter(&end);    // 记录结束TSC值

double elapsed_seconds = (double)(end.QuadPart - start.QuadPart) / freq.QuadPart;
double elapsed_microseconds = elapsed_seconds * 1e6; // 转换为微秒
  • 精度上限：由TSC频率决定（例如3.5 GHz → 理论精度约0.286纳秒）。
  • 实际可达精度：由于中断延迟、总线竞争等因素，通常可稳定达到0.5-2微秒（足以满足微秒级需求）。
  • 关键优势：
    • 连续性：TSC从CPU复位开始计数（无需等待操作系统完全启动）。
    • 无轮询开销：纯硬件读取，无需陷入内核（除首次频率校验外）。
    • 抗干扰：对系统时间调整（如NTP同步）免疫——因为它测量的是间隔，而非绝对时间。

三、为什么不能用其他方式替代？

方法 精度 问题 为何不用于微秒级 uptime
GetTickCount64() 1毫秒 基于系统滴答时钟（默认64Hz更新） 精度太低（1ms = 1000μs）
timeGetTime() 1毫秒 同上，且需要winmm.lib 精度不足
GetSystemTimeAsFileTime() 理论100ns 但受系统时间调整影响（如NTP漂移） 测量间隔时会出现跳变
QueryPerformanceCounter 亚微秒 极少数旧CPU可能TSC不变（需内核后备方案） 唯一可靠选择

⚠️ 重要澄清：
即使LastBootUpTime使用FILETIME存储，其值的产生事件本身就没有微秒级意义。
比如：系统在LastBootUpTime记录的那一毫秒内，可能经历了：
硬件复位 → POST → BIOS → Bootloader → 内核加载 → 驱动初始化 → 会话服务启动
这个过程易受硬件差异、驱动负载影响，波动轻松达到100ms+——讨论其内部是否有“微秒差异”就像在论证沙漏漏沙的纳秒级波动一样，忽略了更大的误差源。

四、实际验证：看看Win10/11的行为

在你的PowerShell输出中：

powershell
Days              : 1
Hours             : 8
Minutes           : 46
Seconds           : 7
Milliseconds      : 843   ← 仅显示到毫秒
TotalMilliseconds : 117967843.29 ← 小数部分 .29 表示 0.29ms = 290μs
  • 这里的.29 恰恰来自于Ticks的小数部分（1 Tick = 100ns → 2900 Tick = 290μs）。
  • 但这并不意味着系统真正知道自己开了机 genau 1.36536855659722 天那么久——
    它只是用当前时间（精确到100ns）减去一个仅精确到毫秒级且语义模糊的开机时间戳。

🔬 要获得真正的微秒级开机时长，正确做法是：

powershell
# 方法1：使用QPC测量从脚本启动到现在的间隔（需在开机极早时注入）
# 方法2：通过内核调试器或ETW追踪内核初始化时间（非普通用户可及）
# 方法3：查看内核日志（如Event ID 6005/6006在System通道中）——但仍仅精确到秒！

本质区别在于“时间基准”

特征 LastBootUpTime QueryPerformanceCounter
时间基准 人为定义的事件（“会话就绪”） 物理时钟事件（CPU复位后每个时钟周期）
更新机制 事件发生时写入注册表（非连续） 硬件持续递增（连续无间断）
精度上限 由事件定义的抖动决定（通常 >1ms） 由CPU主频决定（理论可达纳秒级）
适用场景 审计关机/开机事件 测量任意代码间隔（尤其适合Uptime）
是否能用于微秒级 uptime ❌ 无意义（基准事件本身不精确） ✅ 是（连续硬件计时器）

因此，微秒级运行时长统计必须依赖QPC或等价的硬件计时器（如Linux的clock_gettime(CLOCK_MONOTONIC)），因为它唯一提供了：从系统真正通电开始的、连续不断的、抗干扰的物理时间基准。LastBootUpTime的设计目标注定了它只能用于“粗粒度运行时长”（如判断是否超过1天），而非精密测量。

Get-CimInstance -ClassName Win32_OperatingSystem | Select-Object LastBootUpTime

Get-CimInstance (CimCmdlets) - PowerShell | Microsoft Learn

这个命令会返回操作系统的上次启动时间，功能和 wmic path win32_operatingsystem get lastbootuptime 类似。

解释：

  • Get-CimInstance：用于获取 CIM（公共信息模型）实例的数据。
  • Win32_OperatingSystem：指定要查询的操作系统类。
  • Select-Object LastBootUpTime：筛选并显示操作系统的上次启动时间。

PS C:\Users\Administrator> Get-CimInstance -ClassName Win32_OperatingSystem | Select-Object LastBootUpTime

LastBootUpTime
--------------
2025-09-19 星期五 0:24:13

“LastBootUpTime” 的中文翻译是：

上次启动时间

这是一个信息技术领域的专业术语，尤其在系统管理和监控中非常常见。

分解解释：

  • Last: 上次的，最近的

  • Boot Up: 启动，引导（指计算机开机并加载操作系统的过程）

  • Time: 时间

因此，这个词指的是计算机操作系统最近一次成功启动完成的时间点。

CMD命令 和 PowerShell命令 在修改文件时间方面的对比。我们将常见的文件时间修改操作（如创建时间、访问时间和修改时间）进行对比，并以表格形式展示两者的差异：

操作 CMD命令 PowerShell命令 说明
修改文件的访问时间 copy /b filename +,, $(Get-Item filename).LastAccessTime = "yyyy-MM-dd HH:mm:ss" 在 CMD 中，copy 命令通过拷贝文件并触发时间更新。PowerShell 使用对象模型直接修改时间。
修改文件的修改时间 copy /b filename +,, $(Get-Item filename).LastWriteTime = "yyyy-MM-dd HH:mm:ss" 通过 copy 命令触发文件的修改时间更新。PowerShell 提供了更直观的方法。
修改文件的创建时间 无直接命令，通常通过修改文件内容间接触发创建时间 $(Get-Item filename).CreationTime = "yyyy-MM-dd HH:mm:ss" CMD 中没有直接命令来修改创建时间，需通过其他手段间接更改。PowerShell 直接支持创建时间修改。

解释：

  1. CMD命令：

    • 在 CMD 中，copy /b filename +,, 是一个常见技巧，它利用 copy 命令触发文件的时间更新。此命令会将文件自身复制到自己，借此更新文件的访问时间（LastAccessTime）和修改时间（LastWriteTime）。然而，它没有提供直接修改文件的创建时间（CreationTime）的方法。
    • copy 命令本质上是创建一个新的文件副本，因此 LastAccessTime 和 LastWriteTime 会被更新，但是创建时间不能通过这个命令更改。

  2. PowerShell命令：

    • PowerShell 提供了更灵活且直接的方式来修改文件的时间属性。通过访问文件对象（Get-Item）并直接修改其属性（如 LastAccessTime、LastWriteTime 和 CreationTime），可以轻松地设置文件的时间戳。
    • PowerShell 通过使用 $(Get-Item filename).LastAccessTime = "yyyy-MM-dd HH:mm:ss" 等命令，可以直接设定文件的访问时间、修改时间和创建时间。格式非常灵活，允许通过具体的时间字符串来精确控制时间。
  • CMD 提供的修改文件时间的方式较为间接，通过 copy 命令更新文件的时间戳，但它不支持直接修改创建时间。
  • PowerShell 允许直接修改文件的所有时间戳属性，具有更强的灵活性和控制力，适合更复杂的自动化任务。

CMD命令 和 PowerShell命令 在修改文件时间（包括访问时间、修改时间、创建时间）方面的进一步对比与差异。此表格将涵盖更多常见的操作和命令对比，以帮助你更好地理解两者在处理文件时间的方式。

操作 CMD命令 PowerShell命令 说明
修改文件的访问时间 copy /b filename +,, $(Get-Item filename).LastAccessTime = "yyyy-MM-dd HH:mm:ss" CMD 中使用 copy 命令，通过修改文件内容来更新访问时间。PowerShell 使用对象模型直接修改时间。
修改文件的修改时间 copy /b filename +,, $(Get-Item filename).LastWriteTime = "yyyy-MM-dd HH:mm:ss" CMD 同样使用 copy 命令来更新文件的修改时间。PowerShell 提供更直观的修改方式。
修改文件的创建时间 无直接命令，通常通过间接方式修改文件内容来触发创建时间变化 $(Get-Item filename).CreationTime = "yyyy-MM-dd HH:mm:ss" CMD 没有直接支持修改创建时间的命令。PowerShell 提供直接的方法来修改文件的创建时间。
修改所有时间属性 无法一次性修改多个时间属性 $(Get-Item filename).CreationTime = "yyyy-MM-dd HH:mm:ss"; $(Get-Item filename).LastWriteTime = "yyyy-MM-dd HH:mm:ss"; $(Get-Item filename).LastAccessTime = "yyyy-MM-dd HH:mm:ss" CMD 无法一次性修改所有文件时间戳。PowerShell 可通过链式操作同时修改多个时间属性。
修改特定时间属性（如创建时间） 无法修改创建时间，需借助其他工具或间接方法 $(Get-Item filename).CreationTime = "yyyy-MM-dd HH:mm:ss" 在 CMD 中，无法直接修改创建时间；PowerShell 提供了直接修改创建时间的命令。
修改时间到当前系统时间 copy /b filename +,, $(Get-Item filename).LastWriteTime = (Get-Date) CMD 通过 copy 命令更新访问和修改时间，间接触发当前系统时间。PowerShell 直接获取当前时间并应用。
恢复时间戳为原始时间 无法恢复原始时间，必须依赖外部工具或手动备份 $(Get-Item filename).LastWriteTime = (Get-Date "yyyy-MM-dd HH:mm:ss") CMD 中没有恢复时间的机制。PowerShell 可以通过备份原始时间并重新设置来恢复。
批量修改文件时间 无直接命令，需通过循环或手动操作处理多个文件 `Get-ChildItem "C:\path\to\files" ForEach-Object { $_.LastWriteTime = "yyyy-MM-dd HH:mm:ss" }`
查看文件时间戳 dir filename 或 dir /T:<time_type> filename $(Get-Item filename).CreationTime 或 $(Get-Item filename).LastAccessTime CMD 通过 dir 命令查看文件时间戳，且仅支持查看某一类型的时间。PowerShell 可以查看所有时间戳。
修改文件时间的精度 CMD 命令的时间精度通常只能到分钟级别 PowerShell 可以精确到秒级别，甚至更高（具体取决于文件系统） CMD 对文件时间的修改精度有限。PowerShell 提供了更高精度的时间操作能力。

进一步说明：

  1. CMD命令：

    • CMD 中的 copy /b filename +,, 命令是一种较为"黑科技"的方式，通常用于修改文件的时间戳。此命令的作用是通过复制文件的方式触发文件时间更新。虽然它能更新访问时间和修改时间，但它并没有提供直接修改文件创建时间的方法。
    • 由于缺乏对文件时间属性（如创建时间）的直接支持，CMD 中修改文件时间的操作相对繁琐，且精度较低。

  2. PowerShell命令：

    • PowerShell 提供了直接操作文件时间属性的能力，通过 $(Get-Item filename) 获取文件对象后，可以直接修改 CreationTime、LastWriteTime 和 LastAccessTime，而且精度通常可以达到秒级，甚至更高。
    • PowerShell 还可以通过管道（|）结合 Get-ChildItem 和 ForEach-Object 等命令批量修改多个文件的时间属性，极大地提高了效率。
    • 通过 PowerShell，用户可以灵活地同时修改多个时间戳，并且修改操作简单、直观。
  • CMD命令：适合简单的文件操作，但在修改文件时间方面相对有限，且不支持创建时间的修改。它需要使用一些间接的手段（如 copy 命令）来更新文件时间，无法精确控制时间戳的精度。
  • PowerShell命令：提供了更强大的功能，支持直接修改文件的所有时间戳属性，并且可以处理批量文件、恢复原始时间等任务。PowerShell 的时间操作精度和灵活性更高，适合复杂的自动化需求。

如果需要更多精确控制和批量处理，PowerShell 无疑是更好的选择。

CMD命令 和 PowerShell命令 在 修改文件时间（包括访问时间、修改时间、创建时间）的进一步对比与差异，表格中补充了一些常见的命令细节和操作方式，帮助你更加全面地理解两者的异同。

操作 CMD命令 PowerShell命令 说明
修改文件的访问时间 copy /b filename +,, $(Get-Item filename).LastAccessTime = "yyyy-MM-dd HH:mm:ss" CMD 使用 copy 命令通过操作文件内容触发时间修改。PowerShell 直接修改文件对象的访问时间。
修改文件的修改时间 copy /b filename +,, $(Get-Item filename).LastWriteTime = "yyyy-MM-dd HH:mm:ss" CMD 通过 copy 命令修改文件内容来间接更新修改时间。PowerShell 直接修改文件的修改时间。
修改文件的创建时间 无直接命令，间接方式修改（如 copy 或重命名文件） $(Get-Item filename).CreationTime = "yyyy-MM-dd HH:mm:ss" CMD 无法直接修改文件创建时间，需依赖其他工具或方法。PowerShell 提供直接修改创建时间的能力。
批量修改多个文件时间 for %f in (*.txt) do copy /b "%f" +,, `Get-ChildItem "C:\path\to\files" ForEach-Object { $_.LastWriteTime = "yyyy-MM-dd HH:mm:ss" }`
修改时间为当前系统时间 copy /b filename +,, $(Get-Item filename).LastWriteTime = (Get-Date) CMD 通过 copy 命令更新文件的时间戳为当前时间。PowerShell 使用 Get-Date 获取当前时间并设置。
修改所有时间属性（访问、修改、创建） 无法一次性修改多个时间属性 $(Get-Item filename).CreationTime = "yyyy-MM-dd HH:mm:ss"; $(Get-Item filename).LastWriteTime = "yyyy-MM-dd HH:mm:ss"; $(Get-Item filename).LastAccessTime = "yyyy-MM-dd HH:mm:ss" CMD 不支持一次性修改多个时间戳。PowerShell 可以一次性修改所有文件时间属性。
恢复文件时间戳（从备份文件恢复时间） 无法恢复原始时间，通常需要手动备份时间戳 $(Get-Item filename).CreationTime = (Get-Date "yyyy-MM-dd HH:mm:ss") CMD 无法直接恢复文件时间。PowerShell 可以恢复文件时间，通过备份时间戳并重新设置来恢复。
查看文件的时间戳 dir filename 或 dir /T:<time_type> filename $(Get-Item filename).CreationTime, $(Get-Item filename).LastAccessTime CMD 通过 dir 查看文件时间，支持选择查看特定的时间属性。PowerShell 可以查看所有时间属性。
修改时间戳的精度 精度通常为分钟级 精度为秒级，甚至更高（具体取决于文件系统） CMD 对文件时间的修改精度通常只能到分钟级，PowerShell 可达到秒级甚至更高精度。
修改时间时的副作用 文件内容可能被更改，无法选择性修改时间 只修改时间属性，不改变文件内容 CMD 修改时间时文件内容可能会被意外修改。PowerShell 修改时间时，不会修改文件的内容。
修改文件时间的命令简洁性 命令较为复杂，需要间接触发时间更新，且无法直观查看所有时间属性 命令简洁，通过对象属性操作时间，支持直观查看和修改时间属性 CMD 命令较为繁琐且难以理解，PowerShell 命令简洁直观，适合自动化操作。
支持时间格式 无法直接指定格式，时间格式取决于系统设置 支持自定义时间格式，可以使用 DateTime 格式化操作 CMD 时间格式通常由系统默认控制。PowerShell 支持多种时间格式，可灵活设置。
修改时间时的稳定性 使用 copy 命令时，可能会受到文件锁定或权限问题的影响 修改时间属性时不影响文件内容，并且具有更强的异常处理机制 CMD 修改文件时间时可能遇到文件被占用或权限问题。PowerShell 稳定性更高，且具备错误处理机制。

进一步说明：

  1. CMD命令：

    • CMD 命令修改文件时间的方式比较原始，通常需要借助文件操作（如 copy 命令）来间接修改文件的时间戳。通过修改文件内容来更新访问时间和修改时间，但创建时间无法直接修改。
    • 使用 for 循环可以批量修改文件时间，但是每次都需要通过 copy 来触发更新，效率相对较低，且操作繁琐。
    • CMD 中没有内置支持精确修改文件时间的方式，因此精度受限，并且无法直接恢复文件时间戳。

  2. PowerShell命令：

    • PowerShell 提供了非常直观和灵活的文件时间操作能力。通过对象模型，用户可以直接修改文件的创建时间、修改时间和访问时间，并且可以很方便地批量操作文件。
    • PowerShell 的 Get-Date 命令使得获取当前时间并设置为文件时间戳变得非常简单，可以处理秒级别的时间精度。
    • PowerShell 还支持通过管道批量修改文件时间，支持同时修改多个时间戳属性，不会改变文件内容，且支持恢复文件的时间戳。
  • CMD命令：适合简单的文件操作，但在修改文件时间方面功能有限，且无法精确控制时间戳的精度，通常需要通过间接方式（如 copy 命令）来更新文件时间，效率较低，且对创建时间的修改能力较差。
  • PowerShell命令：提供了更加灵活和强大的功能，支持精确修改文件的创建、访问和修改时间，且可以一次性批量修改多个文件的时间戳。PowerShell 的命令简洁易用，适合复杂的自动化任务。

对于需要高效、精确控制文件时间的任务，PowerShell 无疑是更为强大的工具，而 CMD 更适合简单、快速的命令行操作。

 

posted @ 2024-12-28 00:49  suv789  阅读(2145)  评论(0)    收藏  举报