1.放弃 console.log 吧！源码用 Debugger 你能读懂各种源码
2.Gevent源码剖析（二）：Gevent 运行原理
3.由键盘输入奖金值输出相应的暗示税率和实际应得奖金值分别用if-else的嵌套语句和switch多分支选择语句编写？
放弃 console.log 吧！用 Debugger 你能读懂各种源码
很多同学不清楚为什么要使用debugger进行调试，源码难道console.log不行吗？
即使学会了使用debugger，暗示还是源码有很多代码看不懂，如何调试复杂的暗示云控平台源码源码呢？
这篇文章将为你讲解为什么要使用这些调试工具：console.log vs Debugger。
相信绝大多数同学都会使用console.log进行调试，源码将想查看的暗示变量值打印在控制台。
这种方法可以满足基本需求，源码但遇到对象打印时就无法胜任了。暗示
比如，源码我想查看webpack源码中的暗示compilation对象的值，我尝试打印了一下：
但你会发现，源码当对象的暗示值也是对象时，它不会展开，源码而是打印一个[Object] [Array]这样的字符串。
更严重的是，打印的内容过长会超过缓冲区的大小，在terminal中显示不全：
而使用debugger来运行，在这里设置一个断点查看，qemu 源码 阅读就没有这些问题了：
有些同学可能会说，那打印一个简单的值时使用console.log还是很方便的。
比如这样：
真的吗？
那还不如使用logpoint：
代码执行到这里就会打印：
而且没有污染代码，使用console.log的话，调试完成后这个console也不得不删除掉。
而logpoint不需要，它就是一个断点的设置，不在代码中。
当然，最重要的是debugger调试可以看到调用栈和作用域！
首先是调用栈，它就是代码的执行路线。
比如这个App的函数组件，你可以看到渲染这个函数组件会经历workLoop、beginWork、renderWithHooks等流程：
你可以点击调用栈的每一帧，查看都执行了什么逻辑，用到了什么数据。比如可以看到这个函数组件的.exe源码破解fiber节点：
再就是作用域，点击每一个栈帧就可以看到每个函数的作用域中的变量：
使用debugger可以看到代码的执行路径，每一步的作用域信息。而你使用console.log呢？
只能看到那个变量的值而已。
得到的信息量差距不是一点半点，调试时间长了，别人会对代码的运行流程越来越清晰，而你使用console.log呢？还是老样子，因为你看不到代码执行路径。
所以，不管是调试库的源码还是业务代码，不管是调试Node.js还是网页，都推荐使用debugger打断点，别再用console.log了，即使想打印日志，也可以使用LogPoint。
而且在排查问题的时候，使用debugger的话可以加一个异常断点，代码跑到抛异常的地方就会断住：
可以看到调用栈来理清出错前都走了哪些代码，可以通过作用域来看到每一个变量的app改源码值。
有了这些，排查错误就变得轻松多了！
而你使用console.log呢？
什么也没有，只能自己猜。
Performance
前面说debugger调试可以看到一条代码的执行路径，但是代码的执行路径往往比较曲折。
比如那个React会对每个fiber节点做处理，每个节点都会调用beginWork。处理完之后又会处理下一个节点，再次调用beginWork：
就像你走了一条小路，然后回到大路之后又走了另一条小路，使用debugger只能看到当前这条小路的执行路径，看不到其他小路的路径：
这时候就可以结合Performance工具了，使用Performance工具看到代码执行的全貌，然后用debugger来深入每一条代码执行路径的细节。
SourceMap
sourcemap非常重要，因为我们执行的都是编译打包后的代码，基本是不可读的，调试这种代码也没有什么意义，vlc源码结构而sourcemap就可以让我们直接调试最初的源码。
比如vue，关联了sourcemap之后，我们能直接调试ts源码：
nest.js也是：
不使用sourcemap的话，想搞懂源码，但你调试的是编译后的代码，怎么读懂呢？
读懂一行
前面说的debugger、Performance、SourceMap只是调试代码的工具，那会了调试工具，依然读不懂代码怎么办呢？
我觉得这是不可能的。
为什么这么说呢？
就拿react源码来说：
switch case能读懂吧。三目运算符能读懂吧。函数调用能读懂吧。
每一行代码都能读懂，而全部的代码不就是由这一行行代码组成的么？
加上我们可以单步执行来知道代码执行路径。
为啥每行代码都能读懂，连起来就读不懂了呢？
那应该是代码太多了，而你花的时间不够而已。
先要读懂一行，一个函数，读懂一个小功能的实现流程，慢慢积累，之后了解的越来越多之后，你能读懂的代码就会越多。
总结
这篇文章讲了为什么要使用调试工具，如何读懂复杂代码。
console.log的弊端太多了，大对象打印不全，会超过terminal缓冲区，对象属性不能展开等等，不建议大家使用。即使要打印也可以使用LogPoint。
使用debugger可以看到调用栈，也就是代码的执行路径，每个栈帧的作用域，可以知道代码从开始运行到现在都经历了什么，而console.log只能知道某个变量的值。
此外，报错的时候也可以通过异常断点来梳理代码执行路径来排查报错原因。
但debugger只能看到一条执行路径，可以使用Performance录制代码执行的全流程，然后再结合debugger来深入其中一条路径的执行细节。
此外，只有调试最初的源码才有意义，不然调试编译后的代码会少很多信息。可以通过SourceMap来关联到源码，不管是Vue、React的源码还是Nest.js、Babel等的源码。
会了调试之后，就能调试各种代码了，不存在看不懂的源码，因为每一行代码都是基础的语法，都是能看懂的，如果看不懂，只可能是代码太多了，你需要更多的耐心去读一行行代码、一个个函数、理清一个个功能的实现，慢慢积累就好了。
掌握基于debugger、Performance、SourceMap等调试代码之后，各种网页和Node.js代码都能调试，各种源码都能读懂！
Gevent源码剖析（二）：Gevent 运行原理
Gevent的运行原理在python2.7.5版本下，涉及多个关键概念。简单来说，它通过Greenlet类和Hub事件循环实现并发执行。以下是核心步骤：
首先，通过导入gevent模块，引入其初始化设置，greenlet的运行函数通过gevent.spawn()方法注册到Hub，这个过程包括获取Hub实例、初始化greenlet并保存函数和参数。get_hub()利用线程局部存储保证Hub的多线程一致性。
接着，greenlet通过g.start()注册到事件循环，回调事件由switch()控制，而不是直接运行函数，实现了协程的切换。Gevent提供了join()和joinall()两个入口，其中joinall()控制了整个流程。
在详细流程中，iwait()函数扮演重要角色，通过创建Waiter对象，将协程的switch()链接到目标，通过waiter.get()控制协程执行和返回。Hub事件循环与运行协程通过waiter.get()和waiter.switch()协同工作，实现了并发执行。
目标协程的执行涉及事件循环的启动，通过Cython调用libev库执行。目标函数在run()中执行，并通过_report_result()和_report_error()处理结果或异常。"绿化"函数是实现并发的关键，它们允许在等待I/O操作时释放控制权，从而实现多任务并发。
总的来说，Gevent的运行涉及复杂的协程调度和事件驱动，虽然本文仅触及表面，但其背后的并发机制和技术细节更为丰富，包括异常处理和大量"绿化"函数的使用，这将在后续深入探讨。
由键盘输入奖金值输出相应的税率和实际应得奖金值分别用if-else的嵌套语句和switch多分支选择语句编写？
printf中使用"%%"即可输出%if-else语句代码和运行结果如下：
源码链接为：if-else语句
使用switch语句时可令int d = n/先将n转为对应的整数，再根据d的取值确定r即可
switch多分支语句代码和运行结果如下：
源码链接为： switch多分支语句
注意以上代码在r=0时输出为0而不是0%，若要输出0%可自行修改
两份代码输出均符合样例，望采纳~
