批处理删除指定N天前文件夹的文件：Windows与Linux实践-北京尧图网络

1. 磁盘告警背后的真实场景为什么就是需要一个按天数清理的脚本先讲一个实际场景。某台测试服务器上跑着几个服务日志文件每天都写偶尔还要放一些临时备份包和导出的数据文件。一开始没人在意直到某天监控弹出一条磁盘空间不足的告警登录一看日志目录已经占了三十多个G备份目录里还躺着半年前的压缩包。手动清理花了大半天删完之后没多久新日志又慢慢把磁盘重新填满。问题不是这一波没清干净而是没有一个能按固定节奏自动删除过期文件的机制。这时候win linux批处理删除指定N天前文件夹的文件就成了一个很实际的运维需求。所谓批处理本质上就是把一条删除命令包装成脚本由系统定时触发自动把目录下超过N天的文件清理掉。Windows侧常用的工具是forfiles配合.bat脚本Linux侧则几乎离不开find命令的-mtime参数。两者解决的问题完全一致但语法和边界条件差异很大不能直接平移。为什么强调按天数而不是按大小因为很多业务场景里日志和临时文件的生成速度并不均匀。比如月初导出数据、月底做报表文件可能几天内暴涨一波又比如某个服务平时日志量很小出问题时一小时就能写出好几个G。如果只按目录总大小来清理容易误伤还在使用的近期文件而按时间清理规则简单、可预期只要定好保留周期脚本每次执行的结果都稳定可复现。按天清理天然适合日志、临时文件、过期备份、缓存文件这类越旧越没用的数据。在展开两侧脚本之前先说清楚适用范围。这套方案适合以下场景业务产生的文件按日期自然累积旧文件的价值随时间递减删除之后不需要可回滚。比如应用日志、nginx访问日志、系统临时文件、定期导出的中间数据。如果文件本身需要长期留档审计或者删除操作涉及合规追溯那应该考虑归档和冷存储而不是直接删。另一个前提是清理范围必须能界定清楚。脚本删的是某个目录下的、修改时间早于N天前的、非目录类型的文件。如果目录里既有重要配置又有临时文件一个暴力删除脚本会很危险。所以下面所有实现里我都坚持加上文件类型过滤、时间过滤、以及先模拟后执行的步骤这些不是多余的防御而是脚本能长期跑下去的底线。2. Windows侧落地forfiles批处理的参数拆解与可直接使用的脚本2.1 forfiles命令和它的核心参数Windows从XP时代开始就自带forfiles命令专门用于对指定目录中符合条件的文件执行操作。和find、del的原始组合相比forfiles最大的价值是内置了日期过滤不需要自己写复杂的日期比较逻辑。这里先把它最常用的参数拆开看。参数作用示例/P指定起始目录默认是当前工作目录/P C:\Logs\App/S递归搜索子目录不加/S就只处理当前目录/M文件匹配模式相当于通配符/M *.log 或 /M./D日期筛选核心参数/D 30 表示30天前或更早/C对每个匹配文件执行的命令/C cmd /c del /f /q path/D参数有三种写法需要理解透彻N表示N天以前或更早即删除至少N天前修改的文件-N表示N天以内即保留最近N天常用在反向筛选场景0表示今天。实际清理时我们用D。有个容易混淆的地方Windows下forfiles判断的是文件的最后修改日期不是创建日期也不是访问日期。日志文件一旦写入内容修改时间就是最后写入的时间对清理场景来说是合理的基准。/C参数里可以使用几个内置变量file表示文件名path表示完整路径fdate表示文件日期isdir表示是否为目录。删除文件时一个经典动作是先判断isdir避免把目录也删掉。因为forfiles的递归搜索模式下/M *.*会同时匹配到目录本身如果不加判断del命令虽然删不了目录但整个脚本的行为会变得不可控。2.2 一套可直接落地的Windows清理脚本下面这一份脚本是我在Windows Server环境下长期使用的基础模板。它做的事情很明确检查目标目录是否存在用forfiles递归查找N天前的所有文件并删除同时把操作记录写入日志。echo off setlocal enabledelayedexpansion set TARGET_DIRC:\Logs\AppLogs set KEEP_DAYS30 set LOG_FILED:\Scripts\Logs\cleanup.log if not exist %TARGET_DIR% ( echo [%date% %time%] target directory not exist: %TARGET_DIR% %LOG_FILE% exit /b 0 ) echo [%date% %time%] start cleanup in %TARGET_DIR% %LOG_FILE% forfiles /P %TARGET_DIR% /S /M *.* /D %KEEP_DAYS% /C cmd /c if isdirFALSE del /f /q path echo [%date% %time%] cleanup finished %LOG_FILE% endlocal几个细节说明一下。setlocal enabledelayedexpansion不是必选项但在脚本里如果有变量嵌套或循环建议加上避免批处理的变量展开时机产生意外。if isdirFALSE这一行是防止误删目录的关键forfiles的/C命令里写的是字面量isdirforfiles执行时会替换成TRUE或FALSE大小写不需要担心。del命令加了/f强制删除只读文件加了/q安静模式不弹确认框。日志记录用%date% %time%虽然格式受系统区域设置影响但做运维排查时能看出大概时间就够用。如果希望把日志按天分开避免日志文件无限变大可以在LOG_FILE里加入日期变量。批处理里直接拼接日期容易踩格式坑一个稳妥办法是用wmic或PowerShell动态生成标准日期字符串。for /f tokens2 delims %%I in (wmic OS Get localdatetime /value) do set dt%%I set yesterday%dt:~0,8% set LOG_FILED:\Scripts\Logs\cleanup_%yesterday%.log这种方式生成的是YYYYMMDD格式适合做日志文件的文件名。第一次用的时候可以先跑一次打印出最终生成的LOG_FILE路径看看是否符合预期。2.3 用PowerShell实现的同类脚本如果你的服务器装了Windows Management Framework用PowerShell做同样的事情会更顺手。尤其当目标目录数量多、需要更多条件判断时PowerShell的管道和对象模型比批处理优雅得多。$targetDir C:\Logs\AppLogs $keepDays 30 $cutoff (Get-Date).AddDays(-$keepDays) Get-ChildItem -Path $targetDir -Recurse -File | Where-Object { $_.LastWriteTime -le $cutoff } | Remove-Item -Force -ErrorAction SilentlyContinueGet-ChildItem -File这个参数已经保证了只取文件不会把文件夹对象传给Remove-Item。$cutoff用当前时间减去保留天数得到边界时间任何LastWriteTime早于这个边界的文件都会被删除。这套逻辑更易读也便于扩展比如想排除某些特定文件名在Where-Object里加条件就行。PowerShell还可以把删除的文件信息追加到日志Get-ChildItem -Path $targetDir -Recurse -File | Where-Object { $_.LastWriteTime -le $cutoff } | ForEach-Object { Add-Content -Path D:\Scripts\Logs\cleanup.log -Value $(Get-Date -Format yyyy-MM-dd HH:mm:ss) deleted $($_.FullName) Remove-Item -Path $_.FullName -Force }2.4 Windows路径反斜杠、网络路径与权限问题Windows侧常见的坑集中在三个地方。第一是路径结尾的反斜杠。forfiles对/P C:\Logs\和/P C:\Logs的处理存在差异有时会在拼接路径时出现双反斜杠。稳妥做法是写路径时统一不带末尾反斜杠再用引号包住。第二是权限如果目标目录里有其他进程正在占用的文件del /f会删除失败脚本不会报错也不会中断结果就是日志和实际效果对不上。建议脚本执行结束后再用一个简单的统计指令验证文件数量变化是否符合预期。第三是网络共享路径。forfiles对UNC路径的支持需要额外注意不要把网络路径直接裸奔在任务计划里。如果必须清理共享目录建议先把共享映射为本地盘符或者用PowerShell配合New-PSDrive来访问否则权限和路径解析很容易出问题。此外%date%在中文Windows下会带星期字样如果拼进文件名或日志里可能引入意外的字符这也是我不建议直接用%date%做日期的原因。3. Linux侧落地find -mtime的正确打开方式与三种删除姿势3.1 find的-mtime参数与基础写法Linux下最常用的命令是find。它的-mtime参数按文件内容最后被修改的时间过滤单位是天。-mtime 30表示修改时间距今超过30乘24小时也就是31天以前-mtime -30表示30天以内-mtime 30表示恰好30天前的那24小时内。和Windows forfiles直观的D 30相比find的N边界需要仔细体会很多人第一次用都会栽在这里。一个基础的安全写法find /var/log/app -type f -mtime 30 -delete这条命令的意思在/var/log/app目录下找到所有类型为普通文件的条目且修改时间超过30天直接删除。-type f是不可省略的保护条件没有它find也会把目录当候选对象-delete在删除目录时行为会变得危险尤其是空目录会直接被删掉。除非你确实希望清理空目录否则一律加上-type f。如果需要限定文件后缀名用-name条件find /var/log/app -type f -name *.log -mtime 30 -delete服务器里往往混着log、tmp、zip各种类型加一个-name模式可以缩小清理范围。3.2 三种删除方式对比-delete、-exec rm、xargs同样能实现删除但不同写法在处理文件名空格、日志输出、批量执行上有差异。我把三种方式的特点列了出来。方式命令特点适用场景-delete查找完成后直接删除最简洁文件名规范、不需要记录日志的小规模清理-exec rm -f {} ;每找到一个文件执行一次rm可控制需要按文件逐个处理、可追加日志但性能较差-print0 xargs -0批量传参给rm性能最好安全处理空格文件数量大、文件名可能含空格或特殊字符-exec与xargs里最典型的坑是文件名带空格。如果直接写find ... | xargs rmxargs默认按空白分隔遇到my log file.log会被拆成多个参数导致rm找不到文件。正确姿势是用-print0输出以空字符分隔的文件列表xargs再用-0接收这一组配合可以安全处理任意文件名。find /var/log/app -type f -mtime 30 -print0 | xargs -0 rm -f如果文件数量非常庞大比如几十万个小文件-exec rm -f {} \;的性能瓶颈很明显每删一个文件就要起一个rm进程。此时xargs批处理模式更合适可以一次把大量文件路径传给rm进程启动开销小很多。3.3 先模拟后真删清理脚本的安全测试方法我写任何清理脚本的第一原则都是先看再删。find命令提供了一个绝佳的测试方式——把删除动作去掉只打印匹配到的文件列表。find /var/log/app -type f -mtime 30 -print输出结果里的每一行都是一个将被删除的文件。先跑一次模拟人工扫一眼文件列表确认没有看起来不该删的文件然后再把-print替换成-delete或者重新执行加了删除动作的完整命令。这套习惯花不了多少时间但能避免大多数误删事故。还有一个实用性更强的方法先用交互式脚本把删除文件逐个写到日志再执行rm。#!/bin/bash TARGET_DIR/var/log/app KEEP_DAYS30 LOG_FILE/var/log/cleanup.log find $TARGET_DIR -type f -mtime $KEEP_DAYS | while read -r file; do echo $(date %Y-%m-%d %H:%M:%S) deleting $file $LOG_FILE rm -f $file done这里用while read循环的好处是每删一个文件都能记日志。文件数量不大时完全够用。注意while read -r file配合find输出时如果文件名本身包含换行符会出问题不过日志文件名一般不会出现这种极端情况真遇到再说。文件量大时就不建议这种逐行循环了直接xargs配合日志重定向更高效。3.4 软链接、受限目录与特殊目录的坑find默认不跟随符号链接。也就是说如果/var/log/app/link_dir是一个指向其他位置的软链接find不会进入这个目录去搜索和删除这是好事避免误删链接指向的真实数据。但如果清理目标恰恰需要通过软链接进入另一个目录需要在find加-L或显式指定路径不过我不推荐在清理场景里这么做风险大于收益。删除空目录是另一个容易忽略的点。很多场景下文件删完了目录还留着虽然不影响业务但目录层级会越来越乱。如果想顺手清掉N天前产生的空目录要加上-depth和-empty条件并且用-mindepth 1避免把起始目录本身也当成空目录删掉。find /var/log/app -type d -empty -mtime 30 -depth -delete注意-depth让find先处理子目录再处理父目录这样删空目录时可以从里往外删干净。-mindepth 1的作用是排除起始目录本身如果不加find可能把/var/log/app当空目录删掉。这两条组合是我清理空目录时的标准配置。4. 时间起点与误删防线N天怎么界定哪些文件必须手下留情4.1 Windows和Linux在N天前定义上的差异同样是删除30天前的文件Windows和Linux的判定边界其实并不完全一致。forfiles的/D 30按日期比较匹配的是最后修改日期早于或等于当前日期往前推30天那天的文件边界上刚好是30天整的文件也会被删。find的-mtime 30则按24小时乘以天数精确计算文件修改时间距今大于30个24小时才匹配所以严格来说30天零1秒之前的文件才会被删除刚满30天整的文件不会被删。这个差异在大多数业务场景里不会产生明显影响但你心里得有数。如果业务方要求至少保留30天Windows的forfiles可能把满30天的文件删掉而Linux的find会多留24小时窗口。反过来如果要求只保留最近30天两边都需要再调一天比如Windows用/D 31Linux用-mtime 31避免边界处误判。另一个需要注意的时间维度是文件的时间戳类型。find -mtime看内容修改时间-atime看访问时间-ctime看状态变更时间。Windows的forfiles默认看最后修改时间PowerShell里可以用LastWriteTime。清理临时文件时按修改时间最合理。如果某些业务文件的修改时间长期不变、但访问很频繁按atime清理则更贴近长期未使用的定义。4.2 需要排除保护的文件类型与做法一套清理脚本如果只按时间一刀切迟早会出事。我见过有人在备份目录里混放了需要长期保存的配置文件结果被按天清理的脚本全部误删。防止误删有两种思路一是把备份目录分成不同的子目录按目录分别设定保留周期二是在find命令里用! -name排除关键文件。find /var/log/app -type f -mtime 30 ! -name *.conf ! -name *.key -delete用法可以组合多次! -name也可以写一个包含排除模式的开关。Windows的forfiles同样可以配合嵌套if实现排除但语法更绕不如直接用PowerShell的Where-Object来得直观Get-ChildItem -Path $targetDir -Recurse -File | Where-Object { $_.LastWriteTime -le $cutoff -and $_.Extension -notin (.conf, .key, .pem) } | Remove-Item -Force在代码里明确写出不删什么比把希望寄托在目录规划上可靠一些。如果目录结构本身就很混乱最好的做法是先和业务方确认哪些子目录必须保留然后把它们显式列进exclude配置。4.3 空目录与特殊文件名的处理前面提到Linux下可以用-empty -delete清理空目录Windows下PowerShell也有对应写法先按LastWriteTime过滤目录再判断是否为空最后删除。但空目录的删除有一个前置条件目录里不能有被排除保护的文件。如果某个空目录在排除规则中明确要求保留那它就不该被清理所以目录清理策略要单独设计别把清理旧文件和清理旧目录混在一个规则里。特殊文件名方面Windows的批处理对!和^等符号比较敏感建议文件名里尽量不要出现这些字符或者用PowerShell代替批处理。Linux下文件名里的空格、引号、括号只要用-print0和xargs -0就能稳定处理。真正让我头疼的是文件名里的换行符一旦出现连while read都会出问题这种文件我一般直接手工处理不放进自动化脚本。5. 让清理自动化Windows任务计划与Linux cron的配置细节5.1 Windows任务计划权限、起始于、以最高权限运行脚本写好了剩下的问题是怎么让它按时自动执行。Windows下用任务计划程序创建基本任务这里有几个关键选项配置错了脚本跑不起来或者跑得不对。常规选项卡里勾选使用最高权限运行清理动作经常需要删除其他账户创建的文件权限不够会静默失败。操作选项卡里程序填cmd.exe或直接填批处理文件路径但起始于目录必须填脚本所在目录。批处理文件里如果用了相对路径起始于不对会找不到文件。触发器建议设为每周一次同时把时间选在凌晨业务低峰期。日志文件往往在夜间还有写入选太早可能删不掉刚刚轮转的文件选太晚又可能赶上业务高峰。实际经验是凌晨2点到4点之间相对安全。任务计划创建完成后一定要手动运行一次看任务结果是否成功再去看日志文件确认有没有实际删除动作。很多任务看着显示运行成功实际因为权限或路径问题什么都没干。另一个Windows下容易忽略的点是如果脚本执行时间较长任务计划默认的如果任务运行时间超过X则停止设置可能把任务中断。清理几十万个文件可能需要十几分钟把这个设置改成不停止更稳妥。5.2 Linux cronPATH稀缺、日志重定向、避免重复运行Linux侧的自动化首选cron在root用户的crontab里加一行就行。30 2 * * * /usr/local/sbin/clean_expired_files.sh /var/log/cleanup.log 21意思是每天凌晨2点30分执行清理脚本并把标准输出和错误输出都追加到日志文件。这条cron配置本身没什么坑坑在脚本里。cron环境的PATH极简只有/usr/bin:/bin如果你在脚本里调用了find、date这些命令建议在脚本开头先强制指定PATH。#!/bin/bash export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin不加这句脚本在终端手动执行时一切正常放进cron就报command not found排查半天才发现是PATH问题。除PATH外还需要考虑cron里没有完整的环境变量比如LANG没设置可能导致date输出不是预期格式但这属于细节问题按需处理即可。cron还有一个重复执行的问题。假如清理脚本因为某种原因卡住了比如网络挂载目录无响应下一次cron触发时又启动一个新的清理进程两个进程同时删文件会互相影响。解决办法是在脚本开头加一个锁文件判断。LOCK_FILE/var/run/cleanup.lock if [ -e $LOCK_FILE ]; then echo $(date) previous cleanup still running, exit $LOG_FILE exit 0 fi touch $LOCK_FILE trap rm -f $LOCK_FILE EXITtrap保证脚本退出时把锁文件删除即使中途报错也不会锁死后续任务。这套锁机制简单有效我几乎在所有cron的清理脚本里都加了。5.3 多目录批量配置用一个脚本管理所有清理任务生产环境往往不止一个目录需要清理。日志目录、备份目录、临时导出目录每个目录的保留周期可能不同。与其为每个目录单独写一个脚本注册一个任务不如做一个参数化脚本用配置文件或变量数组驱动多个清理任务。Windows批处理下可以这样组织set KEEP_DAYS30 for %%D in (C:\Logs\App D:\Backup\Tmp E:\Data\Temp) do ( call :clean_dir %%~D ) goto :eof :clean_dir set TARGET_DIR%~1 if not exist %TARGET_DIR% goto :eof forfiles /P %TARGET_DIR% /S /M *.* /D %KEEP_DAYS% /C cmd /c if isdirFALSE del /f /q path goto :eofLinux下直接用数组DAYS30 DIRS( /var/log/app /data/backup/tmp /opt/service/temp ) for dir in ${DIRS[]}; do if [ -d $dir ]; then find $dir -type f -mtime $DAYS -delete fi done列表形式的好处是后续加目录只需改一行。如果不同目录要不同的保留天数把DAYS也变成目录名和天数关联的配置就行比如用目录:天数的写法循环拆分我这边就不展开写了。配置文件驱动的思路本质是一样的脚本读配置配置定义清理策略人只维护配置不碰逻辑。6. 从单目录到全局批量配置、现成轮子与我的实战建议6.1 同样能“删旧文件”的logrotate与tmpwatch聊完自己写脚本回过头看有些场景其实有更成熟的现成工具。Linux自带logrotate专治日志文件轮转。它做的不是简单删除而是按大小或时间把日志切片、压缩、留N份老日志到达保留份数后才会被清理。如果你的目的是管好日志文件logrotate是比find批量删除更正规的方案因为它还能处理压缩、权限、重启通知等一系列细节。tmpwatch这个命令更贴近find删除的用途专门清理目录下长时间未被访问的文件常用于/tmp目录的维护。用法类似tmpwatch -m 48 /tmp表示删除/tmp下超过48小时未被修改的文件。CentOS/RHEL系列自带这个命令Ubuntu系则是tmpreaper。这些工具好不好用取决于发行版和具体场景但如果你的服务器本身就是主流发行版先看看有没有现成机制再决定写不写脚本这个习惯能省不少事。Windows侧对应的现成方案是系统自带的存储感知Storage Sense不过它主要面向Windows客户端的用户配置不适合服务器场景。服务器上更常用的还是任务计划加forfiles或PowerShell脚本没有比这更通用的做法了。6.2 一键式双平台脚本的设计思路如果有整套环境同时包含Windows和Linux服务器可以设计一套统一调用入口的清理方案而不是在每个平台上维护完全不同的逻辑。比如采用配置驱动的思路每个目标目录写一行配置包含路径、保留天数、是否递归、是否跳过子目录同一个小工具在Windows和Linux下各自解析这套配置执行各自的删除策略。Windows侧用PowerShell读取CSV格式的配置Linux侧用bash读取同一份CSV或环境变量文件。这样业务上只需要改一份配置Windows和Linux的脚本都跟着生效。架构上不复杂关键是避免每台服务器上脚本逻辑越来越散。我见过一个环境里每个团队各写各的清理脚本参数五花八门最后运维根本分不清哪个目录谁在管这种场景下统一配置的价值就体现出来了。当然统一的代价是两边的脚本需要各维护一份并且要保持行为一致。对小规模环境来说先各自用最简单的方式跑通比一上来就设计一套分布式统一清理系统更实际。自动化是逐步生长的不是一步到位的。6.3 我的几个实用建议与收尾经验最后结合我自己的实战经验给几个具体建议。第一清理脚本的第一版本一定要先手工跑确认匹配的文件列表符合预期后再交给计划任务。这一步不能省。我自己第一次写forfiles批处理时曾经因为忘记加isdirFALSE判断脚本把子目录也当作删除对象处理虽然最终没有造成实际损失但排查过程很耗时间。从那以后任何删除类脚本都先做只打印不删除的演练。第二日志记录比删除本身更重要。脚本每次执行时把删除时间、目录、文件数记下来。一旦出事第一件事就是查日志确认脚本到底删了什么。没有日志的清理脚本等于裸奔。如果日志量太大可以只记录删除数量而不记录每个文件名但至少要能查到哪次执行删了多少个文件。第三避免精准删除变成暴力删除。任何脚本里都别写裸的rm -rf任何forfiles命令都别裸用/M * /D 0这样的极端组合。保持最小化权限、显式指定目录、显式指定文件类型、显式说明保留天数这四个显式是安全底线。再分享一个我踩过的真实坑某公司的日志清理脚本在Linux上运行正常后来迁移到一台新服务器crontab配置照旧但脚本一直不执行。排查半天发现新服务器的crontab里默认环境变量没有包含脚本依赖的某个工具路径脚本开头也没有强制设置PATH。加上export PATH...之后问题立刻消失。这个坑极其常见也极其隐蔽。现在我的所有cron清理脚本开头永远是#!/bin/bash加一行完整的PATH声明。清理脚本这个事看着简单实际做起来到处是边界细节。但只要把时间基准、文件类型过滤、权限、日志、调度这五件事理清楚它就能长期稳定地替你守着磁盘空间。真正让我觉得值得的不是脚本本身有多精巧而是磁盘满了才发现的那种焦虑变成了每天凌晨自动发生的一次安静清理。

批处理删除指定N天前文件夹的文件：Windows与Linux实践

相关推荐

Ubuntu 26.04 中文输入法：Fcitx5 与 Wayland 排障实践

AI驱动自动化漏洞挖掘流水线：大模型编排、沙箱执行与误报治理

PLC运动控制状态机：MC_Power/MC_Home/MC_MoveRelative串联逻辑与实战避坑

更多资讯

直播美颜SDK性能优化全解析：架构、算法与踩坑实录

RAG检索优化实战：分块、混合召回与重排核心方案

大模型Agent开发全流程：模型选型、工具设计、护栏与编排

SDFT：缓解灾难性遗忘的选择性微调方法，从核心设计到落地实践

模型越强越需要人：Human in the loop落地指南

融合DWA与速度障碍法的移动机器人动态避障实践

今日更新

Verilog实现FPGA密码锁：矩阵键盘与状态机设计实战

数据服务监控运维实战：从指标体系到告警治理与故障排查

FreeRTOS任务通知实战详解：内核原理、API与避坑指南

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？