简介：如何查看电脑使用记录是一份面向普通电脑用户与系统管理维护者的实用doc说明文档，系统讲解通过系统日志、计划任务日志、运行历史、浏览器缓存等途径追踪电脑开关机、程序运行、文档访问及上网浏览记录的具体操作方法。资源包仅含1个doc文件，共30KB，轻量易用，可直接查阅或打印对照操作。目前已有6300人学习下载，适用于需要监控设备使用情况、排查使用痕迹或进行系统维护的入门至进阶用户。文档主体分三大部分展开：一是开机记录，涉及SchedLgU.txt计划任务日志、事件查看器中的eventlog事件筛选，以及systeminfo命令查看开机时长；二是文档记录，通过Prefetch预读取文件夹、Recent最近访问文件、History历史文件夹及事件查看器查找本地操作痕迹；三是上网记录，利用Temporary Internet Files缓存和IE历史记录还原浏览网址。掌握这些方法后，可有效了解电脑使用状况，辅助家长管理、企业审计或个人自查。
1. 电脑使用记录都藏在哪：先想清楚你要查什么
一个反直觉的事实是：Windows 系统里关于“你什么时候用了电脑、用了哪些软件、浏览了哪些网页”这件事，系统自己一直在偷偷记，只是大多数人都不知道去哪翻。很多人一上来就装各种监控软件、翻所谓“上网记录”，实际上系统原生记录、浏览器历史和文件访问痕迹早就把这些覆盖了七八成。这篇笔记围绕“怎么拿到这些记录、怎么把它们变成可读的时间线、再落地成一套能定期自查或做基础审计的方法”展开。适合三种人：想确认自己电脑有没有被动过的人、要做终端使用情况登记的技术人员、以及被要求交“谁用了这台电脑、干过什么”的运维同学。
2. 事件查看器与登录日志：五分钟建立起时间基线
2.1 先认识事件 ID：哪些编号才是真正的“使用痕迹”
Windows 所有和登录、关机、系统行为相关的记录，基本都在“事件查看器”的 Windows 日志里。每次有人开机、注销、成功输错密码、远程登录失败，都会写入对应的事件。很多人打开事件查看器后面对几百条事件无从下手，就是因为不认编号。核心的几个事件 ID 记住即可：
- 4624：登录成功，代表有人成功进入了系统，身份有可能是本机用户、域用户，也可能是服务账户。
- 4625：登录失败，具体是输错密码还是账户不存在，在事件详情里有子状态码。
- 4634 / 4647：注销事件，分别对应当前用户主动注销和因关机导致的注销。
- 6005、6006：事件日志服务启动与停止，基本可以对应到开机与关机瞬间。
- 41（Kernel-Power）：系统意外断电或崩溃，如果夜里有这个事件，说明机器不是正常关机。
这些编号在 Windows 7 到 Windows 11 上基本一致，靠它们可以把“电脑开过机、登录过几次、什么时候关的”这条时间线拉出来。这也是后面所有分析和报表脚本的骨架。
2.2 用一个命令把登录记录导出成可读表格
很多教程让你在事件查看器里一层一层点，然后手动筛选。记录少的时候无所谓，但一台用了半年的电脑，安全日志里可能躺着几万条事件，手工筛选根本不现实。习惯做法是直接用 PowerShell 查安全日志，把结果导成 CSV，再交给 Excel 或脚本去筛选。
Get-WinEvent -LogName Security -MaxEvents 5000 | Where-Object { $_.Id -in 4624,4625,4634,4647 } | Select-Object TimeCreated, Id, @{n='User';e={$_.Properties[5].Value}}, @{n='LogonType';e={$_.Properties[8].Value}}, @{n='SourceIP';e={$_.Properties[18].Value}} | Export-Csv -Path C:\logins.csv -NoTypeInformation -Encoding UTF8这段命令的逻辑是：从安全日志取最近 5000 条事件，只过滤掉登录相关的四个编号，然后挑出时间、事件 ID、用户名、登录类型和来源 IP 五列，导出到 C 盘根目录的 logins.csv。重点解释两个参数：Properties 数组里的下标对应事件 XML 里的字段顺序，第 6 个值是用户名，第 9 个是登录类型，第 19 个是源 IP，这个顺序在 Windows 10 和 Windows 11 上相对稳定。
看到导出的表后，要会看 LogonType 这列，这是判断“是不是真人坐在屏幕前”的关键。LogonType 为 2 是本地键盘交互登录，也就是有人在显示器前面输密码；为 10 是远程交互登录，意味着有人通过远程桌面等手段进过系统；为 3 是网络登录，访问共享文件夹也会触发生成记录。如果一台明明没人用的服务器频繁出现 LogonType 为 2 的登录，那大概率是有人在机房或虚拟机控制台动了它。
查询过程中还要注意，安全日志默认只有启动审核策略之后才记录，如果策略没开，这条命令跑完会提示无法查询。这个问题会在后面避坑章节单独展开。
3. 浏览器与文件痕迹：把“用电脑”补全成完整行为链
3.1 浏览器历史的数据藏在 SQLite 文件里
登录日志告诉你“谁在什么时间进了系统”，但没告诉你“进了系统干了什么”。补全这条链路的头号数据源是浏览器历史。Chrome、Edge 这类基于 Chromium 的浏览器，会把访问过的网页、输入过的 URL、点击时间全部存进一个 SQLite 数据库文件。文件路径在：
C:\Users\你的用户名\AppData\Local\Google\Chrome\User Data\Default\History C:\Users\你的用户名\AppData\Local\Microsoft\Edge\User Data\Default\HistorySQLite 文件不能直接双击打开，拿 DB Browser for SQLite 这一类工具访问即可。真正有用的表是 urls 和 visits：前者记录访问地址和标题，后者记录访问时间。两者通过 url 表的 id 关联。不装图形工具也可以，用 Python 自带 sqlite3 模块读取，几行代码就可以把最近一个月的访问记录按时间排序导出来。
import sqlite3, shutil, os, datetime src = os.path.expandvars(r"%LOCALAPPDATA%\Google\Chrome\User Data\Default\History") dst = r"D:\temp\history_copy" # 浏览器运行时 History 被文件锁占用，复制一份再查 shutil.copy2(src, dst) conn = sqlite3.connect(dst) cur = conn.cursor() rows = cur.execute(""" SELECT datetime(v.visit_time/1000000 - 11644473600, 'unixepoch') AS visit_time, u.url, u.title FROM visits v JOIN urls u ON v.url = u.id ORDER BY v.visit_time DESC LIMIT 200 """).fetchall() for r in rows: print(r)这段代码有几个细节值得留意。第一行通过 expandvars 把 %LOCALAPPDATA% 展开成实际用户目录，能适配不同机器。第二行先复制文件再接库，是因为浏览器进程运行时 History 数据库被占用，直接连接大概率报锁错误，这是很多人第一次写这段代码就翻车的地方。visit_time 字段存储的是 Windows 1601 纪元微秒数，必须经过公式减去 11644473600 再转 unixepoch，否则显示的时间会比实际晚几百年，属于典型的“数据也对但就是离谱”。
3.2 最近打开的文件与运行记录：被忽略的本地痕迹
除了浏览器，系统至少还有两处被忽略的活动记录：最近使用的文件列表和运行管理器的执行记录。前者路径如下：
C:\Users\你的用户名\AppData\Roaming\Microsoft\Windows\Recent Items这个目录下是一堆 .lnk 快捷方式，名称就是文件名，修改时间反映了最近一次打开它的时间。优点是查询极快，不需要任何工具，缺点是有时候系统替换快捷方式而不更新修改时间，所以它适合做“定性”证据，不适合做精准的分钟级时间线。
运行管理器记录的位置在注册表：
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU可以用 reg query 命令直接查看。这个键下保存的是用户在“Win+R”运行框里敲过的命令，对排查“谁在这台电脑上运行过程序”很有用，但它只记最近若干条，而且只记录手动运行过的命令，通过双击快捷方式启动的程序不写进键里。
reg query "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU" /s如果想让这些“点状记录”变成完整的时间线，我一般会再做一步：把 Recent Items 里所有快捷方式的修改时间统一扫一遍，按文件类型归档。一个文件夹几十个快捷方式，靠肉眼看不出规律，脚本扫出来就知道“下午两点大量打开了 Office 文档”，说明那段时间大概率在办公，而不是在刷网页。
当登录日志、浏览器历史、最近文件三份数据拼在一起，一条行为链才算完整：LoginType 2 的登录事件对应“人在机器前”，浏览器记录对应“在上网”，Recent Items 对应“在改文档”。后面要做报表或者审计，就是基于这三份数据的交叉而不是单纯看某一个。
4. 主动监控：从“事后翻记录”到“事前留下痕迹”
4.1 本地安全审核策略：三条必开的审计规则
前面讲的都是被动查已有记录。但默认的 Windows 配置并不会把登录日志完整保留，有不少历史记录会被系统自动覆盖，而且像“谁看了某个文件”这种事默认根本不记录。想稳定地查看电脑使用记录，就必须先把系统的审计策略打开。
打开本地安全策略组，依次进入“本地策略 → 审核策略”，关注以下三项：
- 审核登录事件：成功和失败都要选上，这是登录记录的上游开关，不打开的话前面 Get-WinEvent 什么都查不到。
- 审核进程创建：成功选项勾上。进程创建是排查“运行过什么程序、有没有启动奇怪的 exe”的关键数据来源。
- 审核对象访问：这个慎开，它会针对特定文件夹的每一次访问生成事件，日志增长速度很快，不是必要不要全局开，而是配合特定目录的审计属性单独配。
配置方式不只有图形界面。在管理员权限的终端下可以直接用 auditpol 命令设置，效果相同，适合批量分发到多台机器：
auditpol /set /subcategory:"登录" /failure:enable /success:enable auditpol /set /subcategory:"进程创建" /success:enable auditpol /get /subcategory:"登录"auditpol 的前两个参数指定子类和动作，/set 生效是即时的，不用重启。最后一条 /get 用于校验配置有没有写进去，看到 success/failure 都是 enable 就说明生效。有一点要清楚：改了策略只会影响之后产生的记录，历史缺口是补不回来的，所以“从一开始就把策略设好”才是正路。
4.2 给安全日志加一份自动备份脚本
开了审计之后，日志文件还是会按照大小上限循环覆盖。Windows 默认把 Windows 日志的容量上限设成 20MB 左右，记录多的时候一两天就滚没了。常见的做法是写一个计划任务，每天把安全日志导出留存，同时清出空间给后续记录用——相当于给系统日志做了“归档”。
$timestamp = Get-Date -Format "yyyyMMdd_HHmmss" wevtutil epl Security "D:\EventLogs\Security_$timestamp.evtx" /q:"*[System[(EventID=4624 or EventID=4625 or EventID=4634)]]"wevtutil 的 epl 参数负责导出指定日志中符合查询条件的部分，/q 后面的 XPath 表达式限定只导出登录相关的三类事件，这样归档文件不会因为写入全部日志而迅速膨胀。导出路径需要已经提前建好，不然命令会报错。
导出之后需要确认一件事：归档文件是否可用。可以写一条命令在导出的文件上跑一遍查询，确认事件数量和内容都正常，否则将来等要用的时候才发现文件是坏的，就变成空欢喜一场。
计划任务这一步用“任务计划程序”配置即可，触发器设为每天零点，操作为启动 PowerShell 并执行上面脚本，运行身份选 SYSTEM 就能免密执行。这个做法不依赖任何第三方软件，Windows 原生就能完成归档，符合大多数内网环境不允许安装额外代理工具的约束。
5. 避坑：为什么你总是查不到记录
5.1 现象：安全日志是空的，一条登录记录都没有
原因：最常见的是“本地安全策略里的审核登录事件”没有开启，默认状态下 Windows 不会记录登录成功事件，安全日志里只有几条系统启动事件。
解决：先运行 auditpol /get /subcategory:"登录"，如果显示 no auditing，就执行前面章节提到的 auditpol /set 命令开启。历史缺口无法恢复，只能往前覆盖。这也是为什么我建议新部署的机器第一时间就要把策略配好，而不是等一个月后需要数据了再回首查看。
5.2 现象：登录日志的时间比实际时间差了 8 小时
原因：事件日志存储的是本地时间，但很多备份或导出脚本里混入了 UTC 时间戳做转换，导致读出来和时钟对不上。另外如果系统时间本身被改过，所有记录都会跟着偏移。
解决：在导出 CSV 时就直接用 TimeCreated 字段的原始值，不要二次做时区换算。判断时间是否可信的标准是：开机事件 6005 的记录时间是否和实际开机时间一致，如果这个都偏了，说明系统时间曾被动过或者时间服务异常，日志的时序就需要谨慎核对了。
5.3 现象：浏览器历史被清空了，任何记录都读不到
原因：浏览器设置里的“清除浏览数据”功能会删掉 History 文件内容，SQLite 里只留下空表。另外系统和浏览器自身在更新时也可能触发历史数据清理，只是用户没注意到弹窗勾选项。
解决：如果你能看到 History 文件但里面 url 表为空，只能说明清理已经发生。想补救要看系统的文件和注册表中是否还有残留痕迹，比如浏览器缓存目录里的缩略图、DNS 缓存等。普通排查场景中这些线索只能证明“上过某个网站”，不能还原具体访问时间和页面。
5.4 现象：登录记录里的来源 IP 全是 127.0.0.1
原因：事件中记录的 SourceIP 是客户端地址，本机登录时写的是 127.0.0.1 而不是真实 IP，这是 Windows 的正常行为，不是配置出错。很多人第一次看到这个地址以为是有人做了端口转发。
解决：要区分登录类型。LogonType 为 2 的本地登录，来源 IP 本就不需要分析；只有 LogonType 为 10 的远程登录，SourceIP 才值得关注。远程登录的 IP 也指向本机回环地址的时候，才需要考虑是不是远程桌面走了环回代理或隧道。
5.5 现象：导出的 CSV 里用户名显示为 SID 而不是账户名
原因：事件日志里存储账号名的方式在某些事件下是字符串、某些事件下只有 SID（安全标识符），特别是域环境或 Windows 11 的某些事件类型里体现得很明显。直接按列导出就会得到一串 S-1-5-21 开头的数字。
解决：导出时不要直接从 Properties 数组里取，改成用事件对象自带的属性解析。下面的代码在取用户名的同时做了 SID 到账户名的转换，虽然多了一层处理，但结果稳定得多：
Get-WinEvent -LogName Security -MaxEvents 5000 | Where-Object Id -eq 4624 | ForEach-Object { $sid = $_.Properties[5].Value try { $user = (New-Object System.Security.Principal.SecurityIdentifier($sid)).Translate([System.Security.Principal.NTAccount]).Value } catch { $user = $sid } [PSCustomObject]@{ Time = $_.TimeCreated; User = $user } }这里的核心是 Windows PowerShell 的 Sid 到账户名翻译机制：把事件里的 SID 转换成 SecurityIdentifier 对象，再调用 Translate 方法翻译为 NTAccount 格式。失败时保留原始 SID，既不会因为一条解析错误中断整个导出流程，又保留排查线索。域环境里如果机器处于离线状态，翻译可能超时，所以 try/catch 非常必要。
6. 进阶技巧：从“能看到记录”到“自动生成使用报告”
多年的血泪经验告诉我，真正有用的不是某个查询命令，而是把查询固化成一套例行机制。我自己常用的落地做法是：每周让计划任务跑一个 PowerShell 脚本，自动把过去七天的登录事件和运行过的程序汇总成一份 HTML 报告，然后发到固定邮箱。这里的关键不是邮件，而是报告里必须包含三个维度的信息：登录会话时间线、非工作时间内的登录提醒、关键程序执行频次。
报告脚本的大致骨架是：用 Get-WinEvent 拉一周安全日志，筛选 4624 事件，按天分组统计登录次数；再读 Security 日志中的 4688 进程创建事件，筛出非白名单程序名；最后把结果拼成 HTML 表格保存。把异常逻辑直接用规则表达：凌晨两点后的成功登录直接标红，比让人对着 CSV 一行行找高效得多。这一步就完成了从“事后查看”到“主动感知”的转变。
其实还有一个容易被忽略的细节：锁屏策略。如果只想防同办公室的人乱动电脑，Win+L 习惯比任何监控工具都管用。记录固然能还原事实，但恢复不了已经被泄露的数据。所以这些日志查询和审计手段，更多是给已经发生的怀疑提供证据，而不是安全托底。用一段为自己电脑搭了半年日志归档脚本的人的经验来说就是：把工具建好不难，难的是每天愿意花五分钟看一眼异常记录的习惯。希望这些经验能帮你在需要的时候，少走些弯路，多留些底牌。
本文还有配套的精品资源，点击获取
