“预读”的意思、由来-中文百科全书

数据预读机制

微软采用的一种全新系统后台数据预读机制，它可以提高系统性能，加快Windows XP/2003的启动速度，经过预读的程序全部存放在系统所在文件夹下的prefetcher目录中（图1），文件名格式类似于下面这个样子： FOXMAIL.EXE-2B721FDE.pf（这是Foxmail的预读文件）。Windows XP/2003虽然采用了预读取机制，但是默认设置下比较保守，我们可以自己来定义程序的预读取方式，大幅度提高系统的性能。

常见问题

在使用Windows XP较长时间后，我们会发现系统运行速度明显慢了下来，用多优化软件、卸载已经安装的软件都解决不了问题。究竟为什么呢？原来罪魁祸首就是预读设置。在 “Windows＼Prefetch”文件夹面有很多个以PF为扩展名的文件，这就是预读文件，如果将里面的文件清空以后，你就会发现系统运行速度又恢复正常了！看来，预读设置可以提高系统速度，但是使用一段时间后，预读文件夹里的文件又会变得很多了，导致系统搜索花费的时间变得很长。而且有些应用程序会产生死链接文件，进而加重了系统搜索的负担。

解决办法

因此，我们应该定期删除这些预读文件，用以提高开机速度。

当然，Windows XP重新设置预读对象是允许的。具体方法是：打开注册表编辑器，依次展开HKEY_LOCAL_MACHINE＼SYSTEM＼ CurrentControlSet＼Control＼Session Manager＼Memory Management＼PrefetchParameters分支，在右侧窗口中双击“EnablePrefetcher”，在打开的“DWORD”值编辑窗口中，可以对Windows XP进行预读设置：

将该值设置为“0”，即为取消预读功能；设置为“1”，系统将只预读应用程序；设置为“2”，系统将只预读Windows系统文件；设置为 “3”，系统将预读Windows系统文件和应用程序。一般我们将该值设置为“2”即可，当然，如果你的计算机配置很高，如使用PIII 800MHz CPU以上的建议将数值数据更改为4或5，也可以保留数值数据为默认值即3。这样可以加快系统运行速度。

prefetch，预存取，这在vista用户可能知道的多些，其实xp下就有这一技术了，只是官方少有这方面介绍，更别提技术文档了。　这是xp一个隐藏的特性，用处是在xp登录进度条出现时，就把c:\\windows\\prefetch目录下的*.pf文件信息预先装载到内存中，以便于提高系统性能。这些*.pf文件是系统和应用程序启动时留下的预存取文件，描述了系统和应用程序每次启动时装载模块的信息和顺序，并且其命名方式中包含一个描述其完整路径的十六进制值。

另外，prefetch目录中还有一个重要文件，就是layout.ini这个磁盘布局初始化文件，它记录了所有预存取程序及文件的加载信息和顺序（按优先级排列），这也为这些程序文件的磁盘分配提供了最优化方案的依据。

局部碎片整理

说到这，不得不提一下“局部碎片整理”，按照官方所说，xp每隔3天就会自动进行一次局部碎片整理，我发现这个整理动作是分步实施的，而且是在系统空闲时才会运行，这多亏了刚装上的SSM截获了defrag的这个动作信息，连命令行参数都一并截获，这个重点留待稍后再说。（其实系统在启动时也可以进行局部碎片整理，使得启动时需要的文件能够被整理到相邻位置，这个功能可以在注册表中开启，HKLM\\SOFTWARE\\Microsoft\\Dfrg\\BootOptimizeFunetion下enable键由默认的N改为Y即可）用Filemon跟踪发现，系统进行局部碎片整理时，先读取layout.ini文件，然后调用defrag针对layout.ini中涉及的文件进行整理，然后把转移信息再写入到layout.ini中，这个自动整理不同于server2003系统的自动碎片整理功能（Auto Defragmenter）。

开启预存取

至于是否开启预存取，有不少争论，但是我坚决认为应该开启，否则系统速度会变得更慢。HKLM\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\Memory Management\\PrefetchParameters目录下，EnablePrefeteher子键的值决定以何种方式开启prefetch，0取消，1只预存取应用程序，2只预存取windows系统文件，3同时存取系统和应用程序文件，xp默认情况下是3。以上这些prefetch相关功能依赖于task schedule计划任务这项服务。

defrag的参数

现在该说那个重点了，系统自动调用的defrag的参数是什么？是-p -s和-b。-p后面跟着一个常量，例如5E4；-s后也跟一个常量，比如000018A4；-b后跟着盘符C：，那么这个命令行的例子就是：defrag.exe -p 5E4 -s 000018A4 -b C: 了。-b这个参数网上一直有传言，说是defrag的隐藏参数，但是官方不给出澄清，我也不知道是否真的存在，这回算是证实了。-b C:就是对预存取的文件进行局部整理，并且每次仅针对一个pf文件相关程序文件进行整理，-p和-s应该就是用来选择哪一个pf的，但具体那两个常量和被选pf文件有什么联系，还有待进一步分析。平时如果想对系统和应用程序文件进行一次优化碎片整理，可以在命令行中敲入defrag.exe C: -b，这样会对所有prefetch文件进行整理，完成后你会觉得系统的速度有一定提升。

经验谈

经验之谈，如果不小心删除了prefetch目录下的文件，尤其是layout.ini文件，如何重建？敲入rundll32.exe advapi32.dll,ProcessIdleTasks命令，然后重启三次系统，就可以重建layout.ini文件，为什么是三次，我也不知道，大概和每隔三天整理一次有关系吧。

windowsxp开机有一个进度条，会一遍一遍的跑，不少人认为只跑两圈就进去的就是开机速度快

网上出现过一种优化方式，修改注册表将所谓的“开机预读取”设置为“不预读”，则可以大大减少进度条“跑”的次数，但是这种“优化方法”出来不久，便有更多的文章指出这是“谬误”，还举出相当多的事例，或是试验，说明不预读并不能减少开机时间，大多的理由是进度条消失后的“黑屏时间”增加。

因为一直用的休眠，所以我一直也没怎么在意。前两天和别人谈到这个问题，我便好好研究一番。

结论是，其实关于这个问题，所谓设置为“不预读”的优化方法也并非谬误，而这个所谓的预读也并非没有用处，否则MS怎么也不会花人力物力弄这么个浪费开机时间的东西。

先说说什么是所谓的“预读取”。预读取分两种，一种是“系统文件预读”，一种是“应用程序预读”。具体的不去讨论，现在只讨论预读取对速度的影响。

我们都有经验，当第一次打开word的时候会等待比较长的时间，硬盘灯不停的在亮，但是关闭再次打开，word启动速度就快得多了。这个其实就是windows的预读取做的优化。windows预读取发现你带开了一个他的预读取数据库没有的应用程序时，他就会将这个应用程序中某些信息在内存中留下一个映象，下次打开这个程序就不用再去硬盘上找文件，能大大加块程序启动速度。

问题来了，内存中的映象重新启动之后就会消失，下次开机启动程序依然很慢，怎么办呢？这就需要“开机预读取”功能。Windows会把使用频率较高的一些应用程序的信息记录下来，每次开机时，就完成一次对程序的预读取，从而大大加快应用程序的启动速度。

你大概已经猜到，那个“进度条”一遍一遍的跑的时候，windows就在进行开机预读取的工作。

因此，如果直接取消掉注册表中的“预读取功能”是一定会大大降低应用程序的启动速度的，当然开机速度会有一定的增加，不过这是得不偿失，因为没有了那一段必要的“系统文件预读取”，在进度条消失之后系统会从硬盘上去寻找大量的系统文件，反而影响启动速度，而且应用程序的启动速度也是一定会大大减慢的。其实比较好的优化办法是这样，找到“开机预读取”的信息，手动把不是很常用，不需要预读取的应用程序删除，尽量减少开机预读取的应用程序的数量，由此来加快启动速度！

位置在x:\\windows\\prefetch下面，命名是 exe文件名-16进制hash.exe

有一些实测数据，一台装了许多应用软件的电脑：

不作处理，开机29s,取消预读取，开机32s，删除prefetch文件夹下面大部分文件后，开机23s,有比较明显的开机速度提升，不过第一次运行应用程序的时候速度的确有所下降，并且prefetch文件夹下文件会自动生成，越来越多！

其中最“有效”的一个文件是NTOSBOOT-B00DFAAD.pf，它可以大大提高Windows的启动速度。如果只求启动速度的话，可以只保留这个文件和Layout.ini，然后将Task Scheduler服务设为手动。

当然，要想真正看到预读效果，必须保证开机后内存占用小于物理内存量。（比如：开机后从任务管理器看出内存占用是480MB，而你的物理内存是256MB的，那么就几乎看不到预读的效果。）

MS网站上对prefetch的解释

Prefetch

All versions of Windows except real-mode Windows 3x are demand-paged operating systems, where file data and code is faulted into memory from disk as an application attempts to access it. Data and code is faulted in page-granular chunks where a page's size is dictated by the CPU's memory management hardware. A page is 4KB on the x86. Prefetching is the process of bringing data and code pages into memory from disk before it's demanded.

In order to know what it should prefetch, the Windows XP Cache Manager monitors the page faults, both those that require that data be read from disk (hard faults) and those that simply require that data already in memory be added to a process's working set (soft faults), that occur during the boot process and application startup. By default it traces through the first two minutes of the boot process, 60 seconds following the time when all Win32 services have finished initializing, or 30 seconds following the start of the user's shell (typically Microsoft Internet Explorer), whichever of these three events occurs first. The Cache Manager also monitors the first 10 seconds of application startup. After collecting a trace that's organized into faults taken on the NTFS Master File Table (MFT) metadata file (if the application accesses files or directories on NTFS volumes), the files referenced, and the directories referenced, it notifies the prefetch component of the Task Scheduler by signaling a named event object.

The Task Scheduler then performs a call to the internal NtQuerySystemInformation system call requesting the trace data. After performing post-processing on the trace data, the Task Scheduler writes it out to a file in the \\Windows\\Prefetch folder. The file's name is the name of the application to which the trace applies followed by a dash and the hexadecimal representation of a hash of the file's path. The file has a .pf extension, so an example would be NOTEPAD.EXE-AF43252301.PF.

An exception to the file name rule is the file that stores the boot's trace, which is always named NTOSBOOT-B00DFAAD.PF (a convolution of the hexadecimal-compatible word BAADF00D, which programmers often use to represent uninitialized data). Only after the Cache Manager has finished the boot trace (the time of which was defined earlier) does it collect page fault information for specific applications.

这个似乎是最影响启动速度的文件，也就是所谓的“系统文件预读取”吧

When the system boots or an application starts, the Cache Manager is called to give it an opportunity to perform prefetching. The Cache Manager looks in the prefetch directory to see if a trace file exists for the prefetch scenario in question. If it does, the Cache Manager calls NTFS to prefetch any MFT metadata file references, reads in the contents of each of the directories referenced, and finally opens each file referenced. It then calls the Memory Manager to read in any data and code specified in the trace that's not already in memory. The Memory Manager initiates all of the reads asynchronously and then waits for them to complete before letting an application's startup continue.

How does this scheme provide a performance benefit? The answer lies in the fact that during typical system boot or application startup, the order of faults is such that some pages are brought in from one part of a file, then from another part of the same file, then pages are read from a different file, then perhaps from a directory, and so on. This jumping around results in moving the heads around on the disk. Microsoft has learned through analysis that this slows boot and application startup times. By prefetching data from a file or directory all at once before accessing another one, this scattered seeking for data on the disk is greatly reduced or eliminated, thus improving the overall time for system and application startup.

Figure 1 Prefetch Directory

To minimize seeking even further, every three days or so, during system idle periods, the Task Scheduler organizes a list of files and directories in the order that they are referenced during a boot or application start, and stores the list in a file named \\Windows\\Prefech\\Layout.ini. Figure 1 shows the contents of a prefetch directory, highlighting the layout file. Then it launches the system defragmenter with a command-line option that tells the defragmenter to defragment based on the contents of the file instead of performing a full defrag. The defragmenter finds a contiguous area on each volume large enough to hold all the listed files and directories that reside on that volume and then moves them in their entirety into that area so that they are stored one after the other. Thus, future prefetch operations will even be more efficient because all the data to be read in is now stored physically on the disk in the order it will be read. Since the number of files defragmented for prefetching is usually only in the hundreds, this defragmentation is much faster than full defragmentations.

词条	预读
释义	预读是微软采用的一种加速程序进程启动速度的技术，主要原理是在开机加载操作系统的时候读取常用程序的主要内容以备该程序启动时耗费大量时间来读取本身的数据。数据预读机制常见问题解决办法局部碎片整理开启预存取 defrag的参数经验谈 MS网站上对prefetch的解释数据预读机制微软采用的一种全新系统后台数据预读机制，它可以提高系统性能，加快Windows XP/2003的启动速度，经过预读的程序全部存放在系统所在文件夹下的prefetcher目录中（图1），文件名格式类似于下面这个样子： FOXMAIL.EXE-2B721FDE.pf（这是Foxmail的预读文件）。Windows XP/2003虽然采用了预读取机制，但是默认设置下比较保守，我们可以自己来定义程序的预读取方式，大幅度提高系统的性能。常见问题在使用Windows XP较长时间后，我们会发现系统运行速度明显慢了下来，用多优化软件、卸载已经安装的软件都解决不了问题。究竟为什么呢？原来罪魁祸首就是预读设置。在 “Windows＼Prefetch”文件夹面有很多个以PF为扩展名的文件，这就是预读文件，如果将里面的文件清空以后，你就会发现系统运行速度又恢复正常了！看来，预读设置可以提高系统速度，但是使用一段时间后，预读文件夹里的文件又会变得很多了，导致系统搜索花费的时间变得很长。而且有些应用程序会产生死链接文件，进而加重了系统搜索的负担。解决办法因此，我们应该定期删除这些预读文件，用以提高开机速度。当然，Windows XP重新设置预读对象是允许的。具体方法是：打开注册表编辑器，依次展开HKEY_LOCAL_MACHINE＼SYSTEM＼ CurrentControlSet＼Control＼Session Manager＼Memory Management＼PrefetchParameters分支，在右侧窗口中双击“EnablePrefetcher”，在打开的“DWORD”值编辑窗口中，可以对Windows XP进行预读设置：将该值设置为“0”，即为取消预读功能；设置为“1”，系统将只预读应用程序；设置为“2”，系统将只预读Windows系统文件；设置为 “3”，系统将预读Windows系统文件和应用程序。一般我们将该值设置为“2”即可，当然，如果你的计算机配置很高，如使用PIII 800MHz CPU以上的建议将数值数据更改为4或5，也可以保留数值数据为默认值即3。这样可以加快系统运行速度。 prefetch，预存取，这在vista用户可能知道的多些，其实xp下就有这一技术了，只是官方少有这方面介绍，更别提技术文档了。　这是xp一个隐藏的特性，用处是在xp登录进度条出现时，就把c:\\windows\\prefetch目录下的.pf文件信息预先装载到内存中，以便于提高系统性能。这些.pf文件是系统和应用程序启动时留下的预存取文件，描述了系统和应用程序每次启动时装载模块的信息和顺序，并且其命名方式中包含一个描述其完整路径的十六进制值。另外，prefetch目录中还有一个重要文件，就是layout.ini这个磁盘布局初始化文件，它记录了所有预存取程序及文件的加载信息和顺序（按优先级排列），这也为这些程序文件的磁盘分配提供了最优化方案的依据。局部碎片整理说到这，不得不提一下“局部碎片整理”，按照官方所说，xp每隔3天就会自动进行一次局部碎片整理，我发现这个整理动作是分步实施的，而且是在系统空闲时才会运行，这多亏了刚装上的SSM截获了defrag的这个动作信息，连命令行参数都一并截获，这个重点留待稍后再说。（其实系统在启动时也可以进行局部碎片整理，使得启动时需要的文件能够被整理到相邻位置，这个功能可以在注册表中开启，HKLM\\SOFTWARE\\Microsoft\\Dfrg\\BootOptimizeFunetion下enable键由默认的N改为Y即可）用Filemon跟踪发现，系统进行局部碎片整理时，先读取layout.ini文件，然后调用defrag针对layout.ini中涉及的文件进行整理，然后把转移信息再写入到layout.ini中，这个自动整理不同于server2003系统的自动碎片整理功能（Auto Defragmenter）。开启预存取至于是否开启预存取，有不少争论，但是我坚决认为应该开启，否则系统速度会变得更慢。HKLM\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\Memory Management\\PrefetchParameters目录下，EnablePrefeteher子键的值决定以何种方式开启prefetch，0取消，1只预存取应用程序，2只预存取windows系统文件，3同时存取系统和应用程序文件，xp默认情况下是3。以上这些prefetch相关功能依赖于task schedule计划任务这项服务。 defrag的参数现在该说那个重点了，系统自动调用的defrag的参数是什么？是-p -s和-b。-p后面跟着一个常量，例如5E4；-s后也跟一个常量，比如000018A4；-b后跟着盘符C：，那么这个命令行的例子就是：defrag.exe -p 5E4 -s 000018A4 -b C: 了。-b这个参数网上一直有传言，说是defrag的隐藏参数，但是官方不给出澄清，我也不知道是否真的存在，这回算是证实了。-b C:就是对预存取的文件进行局部整理，并且每次仅针对一个pf文件相关程序文件进行整理，-p和-s应该就是用来选择哪一个pf的，但具体那两个常量和被选pf文件有什么联系，还有待进一步分析。平时如果想对系统和应用程序文件进行一次优化碎片整理，可以在命令行中敲入defrag.exe C: -b，这样会对所有prefetch文件进行整理，完成后你会觉得系统的速度有一定提升。经验谈经验之谈，如果不小心删除了prefetch目录下的文件，尤其是layout.ini文件，如何重建？敲入rundll32.exe advapi32.dll,ProcessIdleTasks命令，然后重启三次系统，就可以重建layout.ini文件，为什么是三次，我也不知道，大概和每隔三天整理一次有关系吧。 windowsxp开机有一个进度条，会一遍一遍的跑，不少人认为只跑两圈就进去的就是开机速度快网上出现过一种优化方式，修改注册表将所谓的“开机预读取”设置为“不预读”，则可以大大减少进度条“跑”的次数，但是这种“优化方法”出来不久，便有更多的文章指出这是“谬误”，还举出相当多的事例，或是试验，说明不预读并不能减少开机时间，大多的理由是进度条消失后的“黑屏时间”增加。因为一直用的休眠，所以我一直也没怎么在意。前两天和别人谈到这个问题，我便好好研究一番。结论是，其实关于这个问题，所谓设置为“不预读”的优化方法也并非谬误，而这个所谓的预读也并非没有用处，否则MS怎么也不会花人力物力弄这么个浪费开机时间的东西。先说说什么是所谓的“预读取”。预读取分两种，一种是“系统文件预读”，一种是“应用程序预读”。具体的不去讨论，现在只讨论预读取对速度的影响。我们都有经验，当第一次打开word的时候会等待比较长的时间，硬盘灯不停的在亮，但是关闭再次打开，word启动速度就快得多了。这个其实就是windows的预读取做的优化。windows预读取发现你带开了一个他的预读取数据库没有的应用程序时，他就会将这个应用程序中某些信息在内存中留下一个映象，下次打开这个程序就不用再去硬盘上找文件，能大大加块程序启动速度。问题来了，内存中的映象重新启动之后就会消失，下次开机启动程序依然很慢，怎么办呢？这就需要“开机预读取”功能。Windows会把使用频率较高的一些应用程序的信息记录下来，每次开机时，就完成一次对程序的预读取，从而大大加快应用程序的启动速度。你大概已经猜到，那个“进度条”一遍一遍的跑的时候，windows就在进行开机预读取的工作。因此，如果直接取消掉注册表中的“预读取功能”是一定会大大降低应用程序的启动速度的，当然开机速度会有一定的增加，不过这是得不偿失，因为没有了那一段必要的“系统文件预读取”，在进度条消失之后系统会从硬盘上去寻找大量的系统文件，反而影响启动速度，而且应用程序的启动速度也是一定会大大减慢的。其实比较好的优化办法是这样，找到“开机预读取”的信息，手动把不是很常用，不需要预读取的应用程序删除，尽量减少开机预读取的应用程序的数量，由此来加快启动速度！位置在x:\\windows\\prefetch下面，命名是 exe文件名-16进制hash.exe 有一些实测数据，一台装了许多应用软件的电脑：不作处理，开机29s,取消预读取，开机32s，删除prefetch文件夹下面大部分文件后，开机23s,有比较明显的开机速度提升，不过第一次运行应用程序的时候速度的确有所下降，并且prefetch文件夹下文件会自动生成，越来越多！其中最“有效”的一个文件是NTOSBOOT-B00DFAAD.pf，它可以大大提高Windows的启动速度。如果只求启动速度的话，可以只保留这个文件和Layout.ini，然后将Task Scheduler服务设为手动。当然，要想真正看到预读效果，必须保证开机后内存占用小于物理内存量。（比如：开机后从任务管理器看出内存占用是480MB，而你的物理内存是256MB的，那么就几乎看不到预读的效果。） MS网站上对prefetch的解释 Prefetch All versions of Windows except real-mode Windows 3x are demand-paged operating systems, where file data and code is faulted into memory from disk as an application attempts to access it. Data and code is faulted in page-granular chunks where a page's size is dictated by the CPU's memory management hardware. A page is 4KB on the x86. Prefetching is the process of bringing data and code pages into memory from disk before it's demanded. In order to know what it should prefetch, the Windows XP Cache Manager monitors the page faults, both those that require that data be read from disk (hard faults) and those that simply require that data already in memory be added to a process's working set (soft faults), that occur during the boot process and application startup. By default it traces through the first two minutes of the boot process, 60 seconds following the time when all Win32 services have finished initializing, or 30 seconds following the start of the user's shell (typically Microsoft Internet Explorer), whichever of these three events occurs first. The Cache Manager also monitors the first 10 seconds of application startup. After collecting a trace that's organized into faults taken on the NTFS Master File Table (MFT) metadata file (if the application accesses files or directories on NTFS volumes), the files referenced, and the directories referenced, it notifies the prefetch component of the Task Scheduler by signaling a named event object. The Task Scheduler then performs a call to the internal NtQuerySystemInformation system call requesting the trace data. After performing post-processing on the trace data, the Task Scheduler writes it out to a file in the \\Windows\\Prefetch folder. The file's name is the name of the application to which the trace applies followed by a dash and the hexadecimal representation of a hash of the file's path. The file has a .pf extension, so an example would be NOTEPAD.EXE-AF43252301.PF. An exception to the file name rule is the file that stores the boot's trace, which is always named NTOSBOOT-B00DFAAD.PF (a convolution of the hexadecimal-compatible word BAADF00D, which programmers often use to represent uninitialized data). Only after the Cache Manager has finished the boot trace (the time of which was defined earlier) does it collect page fault information for specific applications. 这个似乎是最影响启动速度的文件，也就是所谓的“系统文件预读取”吧 When the system boots or an application starts, the Cache Manager is called to give it an opportunity to perform prefetching. The Cache Manager looks in the prefetch directory to see if a trace file exists for the prefetch scenario in question. If it does, the Cache Manager calls NTFS to prefetch any MFT metadata file references, reads in the contents of each of the directories referenced, and finally opens each file referenced. It then calls the Memory Manager to read in any data and code specified in the trace that's not already in memory. The Memory Manager initiates all of the reads asynchronously and then waits for them to complete before letting an application's startup continue. How does this scheme provide a performance benefit? The answer lies in the fact that during typical system boot or application startup, the order of faults is such that some pages are brought in from one part of a file, then from another part of the same file, then pages are read from a different file, then perhaps from a directory, and so on. This jumping around results in moving the heads around on the disk. Microsoft has learned through analysis that this slows boot and application startup times. By prefetching data from a file or directory all at once before accessing another one, this scattered seeking for data on the disk is greatly reduced or eliminated, thus improving the overall time for system and application startup. Figure 1 Prefetch Directory To minimize seeking even further, every three days or so, during system idle periods, the Task Scheduler organizes a list of files and directories in the order that they are referenced during a boot or application start, and stores the list in a file named \\Windows\\Prefech\\Layout.ini. Figure 1 shows the contents of a prefetch directory, highlighting the layout file. Then it launches the system defragmenter with a command-line option that tells the defragmenter to defragment based on the contents of the file instead of performing a full defrag. The defragmenter finds a contiguous area on each volume large enough to hold all the listed files and directories that reside on that volume and then moves them in their entirety into that area so that they are stored one after the other. Thus, future prefetch operations will even be more efficient because all the data to be read in is now stored physically on the disk in the order it will be read. Since the number of files defragmented for prefetching is usually only in the hundreds, this defragmentation is much faster than full defragmentations.
随便看	初贬官过望秦岭初步初步冻伤初步普查初步设计初步设计概算初步审定初步询价初步业务活动初才富初查初缠恋后的2人世界初缠恋后的二人世界初长祥初潮初尘初晨初程初持初出金门寻王侍御不遇咏壁上鹦鹉初出茅庐初出茅庐破大案初创初创企业初春