皮皮网

【snkrs源码】【fuser 命令源码下载】【spring源码环境构建】registers源码

2024-12-27 15:00:39 来源:matlab gui源码

1.PCIe 64 bit不可预取的BAR 地址分配
2.GDB常用命令
3.C语言调试的作用C语言调试器是如何工作的
4.Vue2源码解析?2?初始化

registers源码

PCIe 64 bit不可预取的BAR 地址分配

       对于 bit不可预取的Base Address Registers (BAR) 设备,软件在分配地址时是可行的。关键在于系统是否具备足够的non-prefetchable窗口资源。在PCIe协议中,位可预取BAR被推荐使用,但在某些情况下,snkrs源码如果没有位预取窗口资源,会从位预取窗口中分配。对于那些需要大量不可预取内存空间的设备,如果平台的非预取内存空间有限,可能会影响其在平台上的支持数量。因此,为了充分利用资源,建议这类设备的BAR设置为可预取,尽管对于 bit不可预取的设备,分配地址是可能的,但资源的可用性是前提条件。

       在内核的PCI源码中,如drivers/pci/setup-bus.c中的pci_assign_unassigned_root_bus_resources()和__pci_bus_size_bridges()函数,显示了这种分配机制。如果存在non-prefetchable窗口资源, bit不可预取的BAR设备就能获得相应的地址。然而,如果资源不足,分配将依据平台的限制进行。

GDB常用命令

       三、GDB基本使用命令:

       1、运行命令:启动GDB并加载目标程序,输入命令`gdb ./your_program`,进入GDB交互模式。

       2、断点:设置断点以暂停程序在特定行或函数调用的执行。输入命令`break`后,使用`break function_name`或在源代码中点击断点标记设置具体断点。fuser 命令源码下载

       3、查看源码:在GDB交互模式中,使用`disassemble function_name`或`disassemble`查看指定函数的机器码。使用`disassemble`时,GDB将从当前断点位置开始显示。

       4、打印表达式:在GDB中执行特定表达式并获取其值。使用命令`print expression`即可。例如,要查看变量`x`的值,输入`print x`。

       5、查看运行信息:在程序执行过程中,使用`info locals`查看局部变量,使用`info registers`查看寄存器状态,使用`info thread`查看当前线程信息。`info`命令后可跟参数以获取更多细节。

       6、分割窗口:在GDB交互模式中,使用`split`命令创建新的子窗口。通过子窗口,可以同时在多个窗口中查看和操作目标程序的不同方面,提高调试效率。

C语言调试的作用C语言调试器是如何工作的

       C语言调试的作用,C语言调试器是如何工作的很多人还不知道,现在让我们一起来看看吧!

       C语言调试器是如何工作的

       当你用GDB 的时候,可以看到它完全控制了应用程序进程。当你在程序运行的时候用 Ctrl + C,程序的运行就能够终止,而GDB能展示它的当前地址、堆栈跟踪信息之类的内容。你知道C语言调试器是spring源码环境构建如何工作的吗?下面是小编为大家带来的关于C语言调试器是如何工作的的知识,欢迎阅读。

       但是它们怎么不工作呢?

       开始,让我们先研究它怎样才会不工作。它不能通过阅读和分析程序的二进制信息来模拟程序的运行。它其实能做,而那应该能起作用(Valgrind 内存调试器就是这样工作的),但是这样的话会很慢。Valgrind会让程序慢倍,但是GDB不会。它的工作机制与Qemu虚拟机一样。

       所以到底是怎么回事?黑魔法?……不,如果那样的话就太简单了。

       另一种猜想?……?破解!是的,这里正是这样的。操作系统内核也提供了一些帮助。

       首先,关于Linux的进程机制需要了解一件事:父进程可以获得子进程的附加信息,也能够ptrace它们。并且你可以猜到的是,调试器是被调试的进程的父进程(或者它会变成父进程,在Linux中进程可以将一个进程变为自己子进程:-))

       Linux Ptrace API

       Linux Ptrace API 允许一个(调试器)进程来获取低等级的其他(被调试的)进程的信息。特别的,这个调试器可以:

       读写被调试进程的内存 :PTRACE_PEEKTEXT、PTRACE_PEEKUSER、PTRACE_POKE……

       读写被调试进程的CPU寄存器 PTRACE_GETREGSET、PTRACE_SETREGS

       因系统活动而被提醒:PTRACE_O_TRACEEXEC, PTRACE_O_TRACECLONE, PTRACE_O_EXITKILL, PTRACE_SYSCALL(你可以通过这些标识区分exec syscall、clone、exit以及其他系统调用)

       控制它的执行:PTRACE_SINGLESTEP、PTRACE_KILL、PTRACE_INTERRUPT、PTRACE_CONT (注意,CPU在这里是单步执行)

       修改它的信号处理:PTRACE_GETSIGINFO、PTRACE_SETSIGINFO

       Ptrace是驾校约车源码如何实现的?

       Ptrace的实现不在本文讨论的范围内,所以我不想进一步讨论,只是简单地解释它是如何工作的(我不是内核专家,如果我说错了请一定指出来,并原谅我过分简化:-))

       Ptrace 是Linux内核的一部分,所以它能够获取进程所有内核级信息:

       读写数据?Linux有copy_to/from_user。

       获取CPU寄存器?用copy_regset_to/from_user很轻松(这里没有什么复杂的,因为CPU寄存器在进程未被调度时保存在Linux的struct task_struct *调度结构中)。

       修改信号处理?更新域last_siginfo

       单步执行?在处理器出发执行前,设置进程task结构的right flag(ARM、x)

       Ptrace是在很多计划的操作中被Hooked(搜索 ptrace_event函数),所以它可以在被询问时(PTRACE_O_TRACEEXEC选项和与它相关的),向调试器发出一个SIGTRAP信号。

       没有Ptrace的系统会怎么样呢?

       这个解释超出了特定的Linux本地调试,但是对于大部分其他环境是合理的。要了解GDB在不同目标平台请求的内容,你可以看一下它在目标栈里面的操作。

       在这个目标接口里,你可以看到所有C调试需要的高级操作:

       struct target_ops

       {

       struct target_ops *beneath;

       /* To the target under this one. */

       const char *to_shortname;

       /* Name this target type */

       const char *to_longname;

       /* Name for printing */

       const char *to_doc;

       /* Documentation. Does not include trailing

       newline, and starts with a one-line descrip-

       tion (probably similar to to_longname). */

       void (*to_attach) (struct target_ops *ops, const char *, int);

       void (*to_fetch_registers) (struct target_ops *, struct regcache *, int);

       void (*to_store_registers) (struct target_ops *, struct regcache *, int);

       int (*to__breakpoint) (struct target_ops *, struct gdbarch *,

       struct bp_target_info *);

       int (*to__watchpoint) (struct target_ops *,

       CORE_ADDR, int, int, struct expression *);

       }

       普通的GDB调用这些函数,然后目标相关的组件再实现它们。(概念上)这是一个栈,或者一个金字塔:栈顶的是非常通用的,比如:

       系统特定的Linux

       本地或远程调试

       调试方式特定的(ptrace、ttrace)

       指令集特定的(Linux ARM、Linux x)

       那个远程目标很有趣,因为它通过一个连接协议(TCP/IP、串行端口)把两台“电脑”间的执行栈分离开来。

       那个远程的部分可以是运行在另一台Linux机器上的'gdbserver。但是它也可以是一个硬件调试端口的界面(JTAG) 或者一个虚拟的机器管理程序(比如 Qemu),并能够代替内核和ptrace的功能。那个远程根调试器会查询管理程序的结构,或者直接地查询处理器硬件寄存器来代替对OS内核结构的查询。

       想要深层次学习这个远程协议,Embecosm 写了一篇一个关于不同信息的源码和反码相加详细指南。Gdbserver的事件处理循环在这,而也可以在这里找到Qemu gdb-server stub 。

       总结一下

       我们能看到ptrace的API提供了这里所有底层机制被要求实现的调试器:

       获取exec系统调用并从调用的地方阻止它执行

       查询CPU的寄存器来获得处理器当前指令以及栈的地址

       获取clone或fork事件来检测新线程

       查看并改变数据地址读取并改变内存的变量

       但是这就是一个调试器的全部工作吗?不,这只是那些非常低级的部分……它还会处理符号。这是,链接源程序和二进制文件。被忽视可能也是最重要的的一件事:断点!我会首先解释一下断点是如何工作的,因为这部分内容非常有趣且需要技巧,然后回到符号处理。

       断点不是Ptrace API的一部分

       就像我们之前看到的那样,断点不是ptrace API的一部分。但是我们可以改动内存并获取被调试的程序信号。你看不到其中的相关之处?这是因为断点的实现比较需要技巧并且还要一点hack!让我们来检验一下如何在一个指定的地址设置一个断点。

       1、这个调试器读取(ptrace追踪)存在地址里的二进制指令,并保存在它自己的数据结构中。

       2、它在这个位置写入一个不合法的指令。不管这个指令是啥,只要它是不合法的。

       3、当被调试的程序运行到这个不合法的指令时(或者更准确地说,处理器将内存中的内容设置好时)它不会继续运行(因为它是不合法的)。

       4、在现代多任务系统中,一个不合法的指令不会使整个系统崩溃掉,但是会通过引发一个中断(或错误)把控制权交回给系统内核。

       5、这个中断被Linux翻译成一个SIGTRAP信号,然后被发送到处理器……或者发给它的父进程,就像调试器希望的那样。

       6、调试器获得信号并查看被调试的程序指令指针的值(换言之,是陷入 trap发生的地方)。如果这个IP地址是在断点列表中,那么就是一个调试器的断点(否则就是一个进程中的错误,只需要传过信号并让它崩溃)。

       7、现在,那个被调试的程序已经停在了断点,调试器可以让用户来做任何他/她想要做的事,等待时机合适继续执行。

       8、为了要继续执行,这个调试器需要 1、写入正确的指令来回到被调试的程序的内存; 2、单步执行(继续执行单个CPU指令,伴随着ptrace 单步执行); 3、把非法指令写回去(使得这个执行过程下一次可以再次停止) ;4、让这个执行正常运行

       很整洁,是不是?作为一个旁观的评论,你可以注意到,如果不是所有线程同时停止的话这个算法是不会工作的(因为运行的线程可能会在合法的指令出现时传出断点)。我不会详细讨论GDB是如何解决这个问题的,但在这篇论文里已经说得很详细了:使用GDB不间断调试多线程程序。简要地说,他们把指令写到内存中的其他地方,然后把那个指令的指针指向那个地址并单步执行处理器。但是问题在于一些指令是和地址相关的,比如跳转和条件跳转……

       处理符号和调试信息

       现在,让我们回到信号和调试信息处理。我没有详细地学习这部分,所以只是大体地说一说。

       首先,我们是否可以不使用调试信息和信号地址来调试呢?答案是可以。因为正如我们看到过的那样,所有的低级指令是对CPU寄存器和内存地址来操作的,不是源程序层面的信息。因此,这个到源程序的链接只是为了方便用户。没有调试信息的时候,你看程序的方式就像是处理器(和内核)看到的一样:二进制(汇编)指令和内存字节。GDB不需要进一步的信息来把二进制信息翻译成CPU指令:

       (gdb) x/x $pc # heXadecimal representation

       0xc: 0x 0x 0xf 0xfd

       0xc: 0xa8ec 0x8b 0x8be 0x

       0xc: 0x 0x

       (gdb) x/i $pc # Instruction representation

       => 0xc: push %r

       0xc: push %r

       0xc: push %r

       0xc: push %r

       0xc: mov %rsi,%r

       0xc6b: push %rbp

       0xc6c: mov %edi,%ebp

       0xc6e: push %rbx

       0xc6f: sub $0x3a8,%rsp

       0xc: mov (%rsi),%rdi

       现在,如果我们加上调试信息,GDB能够把符号名称和地址配对:

       (gdb) $pc

       $1 = (void (*)()) 0xc

       你可以通过 nm -a $file 来获取ELF二进制的符号列表:

       nm -a /usr/lib/debug/usr/bin/ls.debug | grep " main"

       c T main

       GDB还会能够展示堆栈跟踪信息(稍后会详细说),但是只有感兴趣的那部分:

       (gdb) where

       #0 write ()

       #1 0xde3 in _IO_new_file_write ()

       #2 0xde4c in new_do_write ()

       #3 _IO_new_do_write ()

       #4 0xd in _IO_new_file_overflow ()

       #5 0xbb in print_current_files ()

       #6 0xb in main ()

       我们现在有了PC地址和相应的函数,就是这样。在一个函数中,你将需要对着汇编来调试!

       现在让我们加入调试信息:就是DWARF规范下的gcc -g选项。我不是特别熟悉这个规范,但我知道它提供的:

       地址到代码行和行到地址的配对

       数据类型的定义,包括typedef和structure

       本地变量和函数参数以及它们的类型

       $ dwarfdump /usr/lib/debug/usr/bin/ls.debug | grep ce4

       0xce4 [, 0] NS

       $ addr2line -e /usr/lib/debug/usr/bin/ls.debug 0xce4

       /usr/src/debug/coreutils-8./src/ls.c:

       试一试dwarfdump来查看二进制文件里嵌入的信息。addr2line也能用到这些信息:

       很多源代码层的调试命令会依赖于这些信息,比如next命令,这会在下一行的地址设置一个断点,那个print命令会依赖于变量的类型来输出(char、int、float,而不是二进制或十六进制)。

       最后总结

       我们已经见过调试器内部的好多方面了,所以我只会最后说几点:

       这个堆栈跟踪信息也是通过当前的帧是向上“解开(unwinded)”的($sp和$bp/#fp),每个堆栈帧处理一次。函数的名称和参数以及本地变量名可以在调试信息中找到。

       监视点(<code>watchpoints)是通过处理器的帮助(如果有)实现的:在寄存器里标记哪些地址应该被监控,然后它会在那内存被读写的时候引发一个异常。如果不支持这项功能,或者你请求的断点超过了处理器所支持的……那么调试器就会回到“手动”监视:一个指令一个指令地执行这个程序,并检查是否当前的操作到达了一个监视点的地址。是的,这很慢!

       反向调试也可以这样进行,记录每个操作的效果,并反向执行。

       条件断点是正常的断点,除非在内部,调试器在将控制权交给用户前检查当前的情况。如果当前的情况不满足,程序将会默默地继续运行。

       还可以玩gdb gdb,或者更好的(好多了)gdb --pid $(pid of gdb),因为把两个调试器放到同一个终端里是疯狂的:-)。还可以调试系统:

       qemu-system-i -gdb tcp::

       gdb --pid $(pidof qemu-system-i)

       gdb /boot/vmlinuz --exec "target remote localhost:"

Vue2源码解析?2?初始化

       活着,最有意义的事情,就是不遗余力地提升自己的认知,拓展自己的认知边界。

       在搭建源码调试环境一节中,我们已经找到了Vue的构造函数,接下来开始探索Vue初始化的流程。

一个小测试

       在精读源码之前,我们可以在一些重要的方法内打印一下日志,熟悉一下这些关键节点的执行顺序。(执行npmrundev后,源码变更后会自动生成新的Vue.js,我们的测试html只需要刷新即可)

在初始化之前,Vue类的构建过程?

       在此过程中,大部分都是原型方法和属性,意味着实例vm可以直接调用

       注意事项:

       1、以$为前缀的属性和方法,在调用_init原型方法的那一刻即可使用

       2、以_为前缀的原型方法和属性,谨慎使用

       3、本章旨在了解Vue为我们提供了哪些工具(用到时,深入研究,不必要在开始时花过多精力,后边遇到时会详细说明)

       4、类方法和属性在newVue()前后都可以使用,原型方法和属性只能在newVue()后使用

定义构造函数//src/core/instance/index.jsfunctionVue(options){ //形式上很简单,就是一个_init方法this._init(options)}挂载原型方法:_init//src/core/instance/init.jsVue.prototype._init=function(options?:Object){ }挂载与state相关的原型属性和原型方法//src/core/instance/state.jsconstdataDef={ }dataDef.get=function(){ returnthis._data}constpropsDef={ }propsDef.get=function(){ returnthis._props}Object.defineProperty(Vue.prototype,'$data',dataDef)Object.defineProperty(Vue.prototype,'$props',propsDef)Vue.prototype.$set=setVue.prototype.$delete=delVue.prototype.$watch=function(expOrFn:string|Function,cb:any,options?:Object):Function{ //略}挂载与事件相关的原型方法//src/core/instance/events.jsconsthookRE=/^hook:/Vue.prototype.$on=function(event:string|Array<string>,fn:Function):Component{ }Vue.prototype.$once=function(event:string,fn:Function):Component{ }Vue.prototype.$off=function(event?:string|Array<string>,fn?:Function):Component{ }Vue.prototype.$emit=function(event:string):Component{ }挂载与生命周期相关的原型方法//src/core/instance/lifecycle.jsVue.prototype._update=function(vnode:VNode,hydrating?:boolean){ }Vue.prototype.$forceUpdate=function(){ }Vue.prototype.$destroy=function(){ }挂载与渲染相关的原型方法//installruntimeconveniencehelpersinstallRenderHelpers(Vue.prototype)Vue.prototype.$nextTick=function(fn:Function){ }Vue.prototype._render=function():VNode{ }挂载Vue类方法和类属性//src/core/global-api/index.js//configconstconfigDef={ }configDef.get=()=>configObject.defineProperty(Vue,'config',configDef)Vue.util={ warn,extend,mergeOptions,defineReactive}Vue.set=setVue.delete=delVue.nextTick=nextTick//2.6explicitobservableAPIVue.observable=<T>(obj:T):T=>{ observe(obj)returnobj}Vue.options=Object.create(null)ASSET_TYPES.forEach(type=>{ Vue.options[type+'s']=Object.create(null)})Vue.options._base=Vueextend(Vue.options.components,builtInComponents)initUse(Vue)//挂载类方法use,用于安装插件(特别特别重要)initMixin(Vue)//挂载类方法mixin,用于全局混入(在Vue3中被新特性取代)initExtend(Vue)//实现Vue.extend函数initAssetRegisters(Vue)//实现Vue.component,Vue.directive,Vue.filter函数挂载平台相关的属性,挂载原型方法$mount//src/platforms/web/runtime/index.js//installplatformspecificutilsVue.config.mustUseProp=mustUsePropVue.config.isReservedTag=isReservedTagVue.config.isReservedAttr=isReservedAttrVue.config.getTagNamespace=getTagNamespaceVue.config.isUnknownElement=isUnknownElement//installplatformruntimedirectives&componentsextend(Vue.options.directives,platformDirectives)extend(Vue.options.components,platformComponents)//installplatformpatchfunctionVue.prototype.__patch__=inBrowser?patch:noopconsole.log('挂载$mount方法')//publicmountmethodVue.prototype.$mount=function(el?:string|Element,hydrating?:boolean):Component{ }拓展$mount方法//src/platforms/web/entry-runtime-with-compiler.jsconstmount=Vue.prototype.$mount//保存之前定义的$mount方法Vue.prototype.$mount=function(el?:string|Element,hydrating?:boolean):Component{ //执行拓展内容returnmount.call(this,el,hydrating)//执行最初定义的$mount方法}Vue的初始化过程(很重要哦!!!)

       熟悉了初始化过程,就会对不同阶段挂载的实例属性了然于胸,了解Vue是如何处理options中的数据,将初始化流程抽象成一个模型,从此,当你看到用户编写的options选项,都可以在这个模型中演练。

       前边我们提到过,Vue的构造函数中只调用了一个_init方法

执行_init方法//src/core/instance/init.jsVue.prototype._init=function(options?:Object){ constvm:Component=this//此刻,Vue的实例已经创建,只是雏形,但Vue的所有原型方法可以调用//aflagtoavoidthisbeingobserved//(observe会在后面的响应式章节详细说明)vm._isVue=true//mergeoptionsif(options&&options._isComponent){ //在后面的Vue组件章节会详细说明//optimizeinternalcomponentinstantiation//sincedynamicoptionsmergingisprettyslow,andnoneofthe//internalcomponentoptionsneedsspecialtreatment.initInternalComponent(vm,options)}else{ vm.$options=mergeOptions(//合并optionsresolveConstructorOptions(vm.constructor),//主要处理包含继承关系的实例()options||{ },vm)}//exposerealselfvm._self=vminitLifecycle(vm)//初始化实例中与生命周期相关的属性initEvents(vm)//处理父组件传递的事件和回调initRender(vm)//初始化与渲染相关的实例属性callHook(vm,'beforeCreate')//调用beforeCreate钩子,即执行beforeCreate中的代码(用户编写)initInjections(vm)//resolveinjectionsbeforedata/props获取注入数据initState(vm)//初始化props、methods、data、computed、watchinitProvide(vm)//resolveprovideafterdata/props提供数据注入callHook(vm,'created')//执行钩子created中的代码(用户编写)if(vm.$options.el){ //DOM容器(通常是指定id的div)vm.$mount(vm.$options.el)//将虚拟DOM转换成真实DOM,然后插入到DOM容器内}}initLifecycle:初始化与生命周期相关的实例属性//src/core/instance/init.jsVue.prototype._init=function(options?:Object){ }0initEvents(vm):处理父组件传递的事件和回调//src/core/instance/init.jsVue.prototype._init=function(options?:Object){ }1initRender(vm):初始化与渲染相关的实例属性//src/core/instance/init.jsVue.prototype._init=function(options?:Object){ }2CallHook(vm,'beforeCreate'):执行beforeCreate钩子

       执行options中,用户编写在beforeCreate中的代码

//src/core/instance/init.jsVue.prototype._init=function(options?:Object){ }3initInjections(vm):resolveinjectionsbeforedata/props获取注入数据//src/core/instance/init.jsVue.prototype._init=function(options?:Object){ }4initState(vm):初始化props、methods、data、computed、watch(划重点啦!!!)//src/core/instance/init.jsVue.prototype._init=function(options?:Object){ }5initProps:初始化props

       此处概念比较多,propsData、props、vm._props、propsOptions,后续会结合实例来分析其区别,此处只做大概了解。

//src/core/instance/init.jsVue.prototype._init=function(options?:Object){ }6initMethods:初始化methods//src/core/instance/init.jsVue.prototype._init=function(options?:Object){ }7initData:初始化data//src/core/instance/init.jsVue.prototype._init=function(options?:Object){ }8initComputed:初始化computed选项//src/core/instance/init.jsVue.prototype._init=function(options?:Object){ }9initWatch:初始化watch

       createWatcher:本质上执行了vm.$watch(expOrFn,handler,options)

//src/core/instance/state.jsconstdataDef={ }dataDef.get=function(){ returnthis._data}constpropsDef={ }propsDef.get=function(){ returnthis._props}Object.defineProperty(Vue.prototype,'$data',dataDef)Object.defineProperty(Vue.prototype,'$props',propsDef)Vue.prototype.$set=setVue.prototype.$delete=delVue.prototype.$watch=function(expOrFn:string|Function,cb:any,options?:Object):Function{ //略}0initProvide(vm):提供数据注入

       为什么provide初始化滞后与inject,后续补充

//src/core/instance/state.jsconstdataDef={ }dataDef.get=function(){ returnthis._data}constpropsDef={ }propsDef.get=function(){ returnthis._props}Object.defineProperty(Vue.prototype,'$data',dataDef)Object.defineProperty(Vue.prototype,'$props',propsDef)Vue.prototype.$set=setVue.prototype.$delete=delVue.prototype.$watch=function(expOrFn:string|Function,cb:any,options?:Object):Function{ //略}1CallHook(vm,'created'):执行created钩子中的代码

       callHook的相关逻辑,参考上面的callHook(vm,'beforeCreate')

执行挂载执行$mount扩展

       通过下面的代码可知:当用户代码中同时包含render,template,el时,它们的优先级依次为:render、template、el

//src/core/instance/state.jsconstdataDef={ }dataDef.get=function(){ returnthis._data}constpropsDef={ }propsDef.get=function(){ returnthis._props}Object.defineProperty(Vue.prototype,'$data',dataDef)Object.defineProperty(Vue.prototype,'$props',propsDef)Vue.prototype.$set=setVue.prototype.$delete=delVue.prototype.$watch=function(expOrFn:string|Function,cb:any,options?:Object):Function{ //略}2

       $mount方法中,首先获取挂载容器,然后执行mountComponent方法

//src/core/instance/state.jsconstdataDef={ }dataDef.get=function(){ returnthis._data}constpropsDef={ }propsDef.get=function(){ returnthis._props}Object.defineProperty(Vue.prototype,'$data',dataDef)Object.defineProperty(Vue.prototype,'$props',propsDef)Vue.prototype.$set=setVue.prototype.$delete=delVue.prototype.$watch=function(expOrFn:string|Function,cb:any,options?:Object):Function{ //略}3//src/core/instance/state.jsconstdataDef={ }dataDef.get=function(){ returnthis._data}constpropsDef={ }propsDef.get=function(){ returnthis._props}Object.defineProperty(Vue.prototype,'$data',dataDef)Object.defineProperty(Vue.prototype,'$props',propsDef)Vue.prototype.$set=setVue.prototype.$delete=delVue.prototype.$watch=function(expOrFn:string|Function,cb:any,options?:Object):Function{ //略}4

       在_update方法中,通过_vnode属性判断是否初次渲染,patch其实就是patch方法,关于patch的详细逻辑,将在diff算法章节详细说明。

//src/core/instance/state.jsconstdataDef={ }dataDef.get=function(){ returnthis._data}constpropsDef={ }propsDef.get=function(){ returnthis._props}Object.defineProperty(Vue.prototype,'$data',dataDef)Object.defineProperty(Vue.prototype,'$props',propsDef)Vue.prototype.$set=setVue.prototype.$delete=delVue.prototype.$watch=function(expOrFn:string|Function,cb:any,options?:Object):Function{ //略}5原文:/post/