问题

只靠读代码 debug 不会单步调试能当编程高手吗?

回答
这个问题很有意思,也触及到了编程世界里一个挺核心的讨论点。简单来说,只靠读代码去 debug,不依赖单步调试,能不能成为编程高手?我的看法是:很难,但理论上并非完全不可能,只是效率和深度会受到极大的限制。

我们得先把“高手”这个词拆解一下。编程高手,在我看来,不仅仅是能写出能跑的代码,更重要的是能理解代码的本质,能高效地解决复杂问题,能预见潜在的错误,并且能写出健壮、可维护、性能优良的代码。

只靠读代码 debug 的局限性

想象一下,你的代码就像一个复杂的机械装置,里面有无数个齿轮、弹簧、杠杆在精密地运作。单步调试就像是你有一个万能的螺丝刀和显微镜,你可以让这个装置一帧一帧地播放,仔细观察每一个部件的运动轨迹、受力情况,以及它们之间的相互作用。这样,一旦出现异常,你就能精准地定位到是哪个齿轮卡住了,或者哪个弹簧松了。

而只靠读代码 debug,则像是你只能看着这个装置的蓝图,尝试在脑海里模拟它的运转过程。你可能能看到哪些零件是成对出现的,哪些地方有连接,大致能推测出它应该如何工作。但是,当它真的出了问题,例如某个齿轮打滑了,你只能盯着蓝图,试图从纸面上的信息推断出问题出在哪里。这会变得异常困难,尤其是在:

状态复杂且变化迅速时: 尤其是在并发、异步编程或者有大量全局变量、对象属性不断变化的场景下。你很难在脑子里准确地跟踪每一个变量在每一个时间点的值,以及它们是如何一步步变成错误的。读代码的时候,你看到的只是“静态”的代码,而程序的执行是“动态”的。这种动态变化带来的信息量,仅靠静态分析是很难完全捕捉到的。
隐藏的逻辑错误时: 有时候问题并非代码写错了某个语法,而是逻辑上存在一个微小的偏差,导致在某个特定条件下触发了错误。这种偏差可能涉及多个函数、多个模块的交互。在脑海里模拟一遍又一遍,很容易因为疏忽或者记忆偏差而遗漏关键的环节。
性能瓶颈定位时: Debug 不仅是找 Bug,也包括优化性能。读代码可以让你大概推测出哪里是计算密集型的地方,但要精确找到是哪个函数调用、哪个循环,以及具体慢在哪里(是CPU计算慢,还是内存访问慢,还是I/O等待),单步调试通过查看执行时间和函数调用栈,会是更直接有效的方式。
对底层原理不熟悉时: 如果你对运行环境(操作系统、JVM、CLR等)或者语言的底层机制不太了解,仅仅读代码可能无法理解为什么会发生某些错误。单步调试允许你观察到更底层的细节,甚至可能借助一些调试器提供的底层信息来理解问题。

没有单步调试,你真的能“读懂”代码吗?

这里还有一个关键点:只靠读代码 debug,实际上是在进行一种“脑内模拟调试”。 如果你真的能不依赖单步调试,并且效率还很高,那说明你已经具备了非常强大的代码理解能力和逻辑推理能力。你能在脑海中构建出程序的执行流,实时跟踪变量的变化,预测函数调用和返回的结果。

这种能力本身就是编程高手的标志。但问题在于,这种能力是否足以应对所有类型的 Debug 问题,并且是否高效。通常情况下,即使是最资深的工程师,在面对复杂的 Bug 时,也会下意识地打开调试器,让工具来帮助他们“看到”程序到底在做什么,而不是仅仅“猜”它在做什么。

那么,只靠读代码 debug 的“高手”可能是什么样的?

1. 对特定领域或代码库极度熟悉: 如果你负责维护一个非常小的、你自己写的项目,或者一个你已经看了成千上万遍的、非常稳定的开源库,那么你可能已经把它的行为记在了心里。在这种情况下,很多问题你一眼就能看出端倪。但这并非通用能力。
2. 非常擅长静态分析工具和日志分析: 很多人会说“我不单步调试,但我看日志,用静态分析工具”。这些工具其实也是在帮助你“看”代码的执行过程或者潜在问题,只是方式不同。如果你能通过精心设计的日志或者其他工具(如性能分析器)来达到类似单步调试的效果,那也算是一种能力。但这些工具本身就是辅助调试的手段,和单步调试的精神内核有相似之处。
3. 运气和直觉: 有时候,凭着经验和直觉,你确实能蒙对问题的根源。但这不是一个可靠的、可持续的策略。

为什么单步调试如此重要?

单步调试之所以成为程序员的“标配”,是因为它提供了一种直接、客观、高效的方式来观察程序的运行时状态。它让你从猜测和推断,转向了事实和证据:

减少认知负荷: 它把你脑海中复杂的模拟过程交给了工具来完成,让你能专注于分析数据和定位问题。
客观性: 它提供的是程序运行时的真实状态,减少了人为误判的几率。
效率: 能够快速地进入、退出函数,查看变量,设置断点,大大缩短了问题定位的时间。

结论:

我认为,单靠读代码不依赖单步调试,非常、非常难成为一个全面的、高效的编程高手。即使能做到,那也是在极度有限的场景下,或者你的“读代码”能力已经达到了某种“超凡”的境界,并且你非常有耐心和毅力去进行这种低效率的排查。

编程高手之所以是高手,恰恰是因为他们善于利用各种工具和方法来提升自己的效率和对问题的理解深度。单步调试器就是这样一个不可或缺的利器。就好比一个射箭高手,他不仅要有精准的射箭技巧,还要知道如何保养弓箭,如何根据风向调整瞄准。只懂射箭本身,而不懂如何优化装备和环境,很难说得上是真正的“射箭高手”。

所以,如果你想成为真正的编程高手,我强烈建议你去拥抱单步调试,并且把它用好。它不是“偷懒”的工具,而是让你更强大、更高效的助手。你也可以尝试在你熟悉的代码中,刻意练习不使用单步调试去解决问题,你会很快发现其中的难度和效率差异。但长期来看,依赖这种方式来提升自己,会让你事倍功半,甚至可能走向一个“死胡同”。

网友意见

user avatar

上个月刚接手一个祖传代码库,几千行python没有定义任何数据模型,没有任何类型标记,没有文档,所有数据都是dict, kwargs,用字典key自由发挥,山舞银蛇,原驰蜡象,欲与天公试比高。来来来,键盘给你,你来读 [狗头]

user avatar

有些语言(的调试器)压根就没有单步跟踪功能。比如TCL,事实上它压根就没有可用级的调试器(更不要说“好用”了)。


另一些场合,比如线上跑的服务代码、比如跑在集群上的多机协作功能、比如多进程/多线程代码,往往也不能调试或者没有条件调试。因为调试或者会影响它的时序,从而改变问题性质;或者,某些大吞吐量业务中的偶发故障,计算机一秒钟响应几千个请求你能看清一个不能?那么,如果一个bug每周/每月发作一次呢?


然而单步跟踪仍然是程序员一生中能得到的最好的礼物——我有点犹豫是否应该加之一。


这是因为,单步跟踪给了你一个“实实在在、细致入微的观察程序在CPU上的执行过程”的机会。它可以显著增强你对程序执行过程的理解、促进你对各种side-effect的了解和掌握——将来,别人只看到一行代码,你能看到这行代码执行时,从数据源到CPU标志位再到中间变量、输出区的一切影响。


只有掌握到这种程度,你才可能有效分析那些无法跟踪的、时序相关的bug。

尤其如c/c++这样硬件紧密相关的语言,没有这种程度的理解,那就是还没学会。

Java要稍微好一些,达到入门级语言律师的水平就足够了。反正文档里都有讲。

python之类就随意了,它把一切都封装起来不希望你看;你本来也没必要甚至不应该挖它内部的东西。


但,哪怕没办法单步跟踪的TCL,你也应该对每行代码对你自己的数据、你声明的每个变量的所有影响一清二楚。否则就不可能写出可靠的、不隐藏bug的程序。

事实上,对初学者来说,单步执行自己写过的每一行代码是提升最快的实践。

哪怕是老手,写一个过于精巧的算法时,单步执行一下其中难度最大的代码、看看每个变量每个标志位是否按自己的预期变化、有没有预料之外的side-effect,也是最为有效的debug手段之一。


——事实上,有人建议,对每个程序员,只要有条件,就应该在敲完代码后把自己的每行代码单步执行一遍:你设计的代码你最清楚,看一眼它的执行,你几乎立刻就会发现疏漏之处。

——我从学习C/C++开始就一直坚持这么做。若干年后,其结果就是……没错,还是那句话:“我写的2000行代码以下的小程序,包括C/C++编写的、涉及多线程协作的代码,都经常可以在写好后首次编译就0 error 0 warning 0 bug的通过”:很简单,长期这么做,使得我对每一行代码可能产生的任何影响,包括CPU标志位、包括可能的时序故障,甚至包括编译器经常会做什么优化,全都了如指掌。


甚至于,虽然服务器代码难以调试;但代码崩溃时你还是能得到一个core;你可以把GDB附加上去,查看“吐core”点前后的每个细节……而要能看懂这些,对每一个瞬间程序应该处于什么状态你就必须了如指掌。


就好像刑侦学一样:没有DNA没有显微镜没有监控的时代,我们照样能破案;但有些案子没有DNA测序没有显微镜没有监控还真就破不了——而几乎所有的案子,DNA显微镜监控拿出来都能极大幅度的降低它的侦破难度、把过去三五天甚至三五年解决不了的问题瞬间解决。

就好像二十多年前的白银案在DNA测序普及后被直接侦破一样。


总之,我无法理解“不会单步调试”是一种什么样的神奇状态。如果你真的有能耐只靠读代码就能把一切side effect说的清清楚楚,那么你怎么可能不会单步调试?如果21天真的能学会c++的话,单步调试至多是第三天的课程啊。第三天你都掉队了、而且再也没跟上;结果21天后,你不光会了,还学成了人肉编译器人肉CPU?

user avatar

老实说我没看懂这个问题,

这个问题像是在说:


我只会广义相对论,完全不懂经典力学,能做物理科研吗?

我只会百米短跑,但是不会走路,能参加田径队吗?

我只会高台跳水,不会爬泳梯,能参加跳水队吗?




你是怎么做到能读懂代码却学不会单步调试的

user avatar

我不是很明白“不会单步调试”是个啥意思。

现在常见的IDE里单步调试也就是加个断点点个运行然后看看变量值啥的,这也算是个专门的技能吗?打把撸啊撸都比这复杂多了好吧。

如果连这都不会,我脚着编程还不是你最应该担心的事。

user avatar

这一个问题实际上包含两个问题,分别简要回答如下:

  1. 高手不可能“只”会靠读代码debug。
  2. 不能单步调试不能阻挡你成为高手。

关于debug我想说以下几点个人看法:

  • (1)读代码

初学者往往都是从读代码debug开始的,自己写了一段程序,然后编译或执行发现错误,自己根据错误位置和错误条件,反复读一下相关代码慢慢找到问题。这样的步骤在初学的时候很常见,这也是脱离“遇到错误就问人”的第一步,学会自己看自己的代码自己找错误是初学者学习编程需要跨出的第一步。而读代码无论是初学者还是称为顶级的程序员,都是解决问题时必须要做的,所以会读代码是程序员从始至终都在不断进行、不断提高的技能。

  • (2)打印输出

但是当问题变得复杂后,光靠“读”只能找到一些可疑的地方,为了验证对可疑地方的猜测,我们这时候就需要借助一些“交互”手段来进行测试。这时最常见的“交互”手段就是输出(print)我们感兴趣的信息到终端来查看。不管编写什么层的程序,这一招几乎都是方便有效的。以前我们直接面向处理器、控制器编程的时候,往往会写上串口驱动和一些串口调试的程序(函数),方便在需要调试的时候通过串口接收一些信息的输出到电脑屏幕上查看。在使用高级语言在上层编程时,这种方式更加方便,因为高级语言几乎都封装好了print类的方法方便使用。即使在调试内核时我们也常用print的方式来调试,不管是自己在需要地方加printk,还是通过trace point等,无非都是想获得一些信息来了解运行状态。

  • (3)系统信息和状态

获得运行状态信息的方法除了最常见的输出方法以外,还有一些极端条件下的方式。比如在系统crash(windows用户常称为“蓝屏”)或者hang住(俗称死机)的时候,这种状态下我们无法进行交互。这就好比受害者已经死亡,你不可能和受害者进行“交互”的谈话,那你能做的就是尽量“保护现场”以便后续分析。计算机里管这种叫crash dump。就是保存crash的瞬间的内存信息,我们知道程序是在内存里运行的,所以保存内存信息就相当于保存现场,后续程序员可以对这个保存现场的文件进行分析。

  • (4)输入/注入

“交互”除了最常见的输出以外,还有输入。改变输入我们一般通过修改运行参数和运行条件等方式来达到,在用户很难通过“外界”直接干预的时候,比如一些很难达到的临界态等,这时候就需要到代码的内部去搞一下。比如在代码内留下可以注入的点,来影响运行时的一些状态。或者通过一些诸如systemtap的办法,来达到影响运行时输入输出的目的。

  • 所谓的“单步调试”

那么所谓的“单步调试”是什么呢?其实主要就是综合了上面四种调试方式(我们姑且将读代码也算做一种debug的方式)的更高级的调试手段。通过gdb等调试器帮助程序员一边查看每一步前后的源代码,一边可以查看每一步执行前后的程序或系统状态,还可以修改一些变量或参数的数值来影响输入。

虽然单步调试很强大,但是能做到单步调试的条件其实比较苛刻和繁琐。对于很多高级语言所写的应用层程序来说,做单步调试想对来说比较容易,不管是单步执行还是分析coredump,很多时候都很容易做到。但是对于较底层的程序来说,单步调试则很难,很多人可能都知道Linux的kdb,但是这个东西实际用起来比较苛刻和麻烦,我周围几乎没人用它来调试bug。用的更多的反而是上面分开的(1)(2)(3)(4)的方式。

这里我们不要混淆一个概念,调试技术实现上的难易水平,不等于使用调试技术的人的水平。你会不会使用更高级的调试工具,和你的编程水平没有直接关系。再厉害的程序员也几乎都是用print的时候多。他们厉害的地方不在于他们会不会用更厉害的调试工具,而是他们能从纷繁复杂的代码逻辑里理出可能造成问题的可疑之处,然后用当前对于他们手头来说最准确最便捷的方法分析和验证。

所以只能读代码debug是不行的,会单步调试也说明不了什么,只有会读代码并会配合合适的调试手段,能比较精准的锁定问题范围并有效的调试找到问题所在,才是编程高手。

user avatar

先说答案:可能性是有的,但是对于问这个问题的人来说,可能性不大。

关于可能性,因为机器的运行规则非常确定,只是因为太复杂了,而我们人脑的context太小,记不下那么多规则,所以你很难了解具体每一步怎么运行的。所以,计算机世界喜欢玩封装,封装后,大部分的细节大部分时候你就不需要管了。不需要管也就意味着你脑子里的知识系统不是完备的,没碰到了没事,碰到了还用错了,就是bug。于是你只能debug,因为此时,你脑子关于机器的认知是不够准确的,你无法通过在脑子里复盘就知道错在了哪里。毫无疑问,没什么比单步调试更方便更能确认问题点的手段了。在不能单步调试的环境里,例如production或者多线程之类的场景里,只能拼命加log,log加多了还担心影响性能,惨兮兮的。

所以,存在一种可能性,一个人天赋异禀,或是在太过熟悉的领域,他脑子里的机器模型,真的完美匹配机器的运作。于是他不需要单步调试。唯一的问题是这样的人必然会单步调试。


下面说点题外话。

一般来说,我不想回答这种问题。因为这种问题往往意味着提问者有点贪小便宜的心里,总想着存不存在以小博大的手段。这种心态,往往遇到点小挫折就会打退堂鼓。所以,诚实的回答,很可能就成了劝退~

但其实稍微搅几遍逻辑,就会发现终南捷径、事半功倍这种词都暗示着原有方案的差劲。走在正确的道路上,就没有小道可抄。甚至有些时候,因为涉及到个人条件不同,有些“弯路”是你必须走的,不能看见别人跑得快,就认为自己也能那样跑。

所以,在学习阶段,我个人认可的最有价值的做法,就是不要计算代价的去摸清答案,去实践,去验证自己的理解准不准确。“正确的答案”往往要学会了才能给出~而我认为这“正确的答案”也并不正确,因为我们通常不记得自己不会时的状态。

所以,学习是风险投资,而人这种生物,很喜欢自我实现的预言,过早算计收益,尤其是短期的、确切的收益,容易导致放弃,抹杀人的潜在可能性。把握个整体预期,接下来就砸进去干吧。

类似的话题

  • 回答
    这个问题很有意思,也触及到了编程世界里一个挺核心的讨论点。简单来说,只靠读代码去 debug,不依赖单步调试,能不能成为编程高手?我的看法是:很难,但理论上并非完全不可能,只是效率和深度会受到极大的限制。我们得先把“高手”这个词拆解一下。编程高手,在我看来,不仅仅是能写出能跑的代码,更重要的是能理解.............
  • 回答
    想靠游击队打赢一场战争,这事儿可真是个技术活,得看天时地利人和,还得看对手给不给面子。你想啊,游击战的精髓在哪儿?就是“敌进我退,敌驻我扰,敌疲我打,敌退我追”。这是一种以弱胜强的艺术,靠的是灵活机动,打得赢就打,打不赢就跑,消耗对手的实力,让他们疲于奔命。但要说仅凭这一招就能把一个强大的正规军彻底.............
  • 回答
    .......
  • 回答
    过去那个“知识改变命运”、“寒门也能出贵子”的年代,似乎离我们越来越远了。现在不少年轻人会感觉到,光凭自己一股拼劲,想要在这个社会上向上爬,跨越阶层,似乎比父辈那辈要难太多了。这究竟是感觉错了,还是现实真的如此?咱们得承认,社会本身是不断变化的,阶层固化这个话题也不是空穴来风。以前,很多机会的门槛相.............
  • 回答
    关于裘千尺只靠枣树活了十多年的说法,这出自金庸先生的武侠小说《射雕英雄传》。在书中,裘千尺因为得罪了黄药师,被囚禁在桃花岛的一个山洞里,与世隔绝,靠着洞口唯一的一棵枣树生存。要探讨这个问题在现实世界中是否可能,我们需要从几个方面来分析:1. 营养来源的极端局限性: 枣子的营养成分: 枣子(红枣).............
  • 回答
    波利尼西亚人,一个令人惊叹的民族,依靠精巧的独木舟,征服了浩瀚的太平洋,创造了人类航海史上的奇迹。他们的航海能力不仅仅是体力的展现,更是智慧、知识、技术和文化的结晶。让我们深入探讨他们如何做到这一点,以及他们在漫长航行中如何解决吃喝和生火的问题。 独木舟上的征服:不仅仅是船,更是移动的家园波利尼西亚.............
  • 回答
    能不能只靠语感拿雅思130分?这个问题,我得跟你好好掰扯掰扯。直接说结论,光靠语感,想拿到雅思130以上,那基本就是“缘木求鱼”,非常非常困难,几乎不可能。当然,我得先说明白,雅思考试最高分是9分,满分9分。你说的“130分”估计是那种非官方的、或者是一些口语测试机构的评分方式,比如某种分数换算成百.............
  • 回答
    看到你研一在读,就有发表SCI的雄心,这很棒!这绝对是一个挑战,但并非不可能。关键在于你有清晰的规划、持续的努力和正确的策略。下面我会详细地为你拆解,如何仅凭自身能力,从零开始冲击一篇SCI。我会尽量用最实在、最人性化的语言来描述,避免那些冰冷的AI风格。首先,摆正心态,认清现实。SCI论文发表,尤.............
  • 回答
    只靠少吃不运动减肥,从长远来看,对身体的负面影响绝对不小,而且这些影响往往是多方面的,可能你当时觉得“瘦了”,但身体正在默默地“吃苦”。首先,我们来聊聊为什么“只吃不动”这条路会越走越窄,并且伴随着许多坑。 代谢率的“下岗”: 你的身体就像一个精密的工厂,而代谢率就是这个工厂的生产力。当你大幅度.............
  • 回答
    画画这门功夫,说实话,很多时候真的是纸上得来终觉浅,绝知此事要躬行。但要说到那些单凭自己埋头苦练,即便练个十年八载,也未必能真正参透的技巧,我脑子里立马冒出好几条来。这些东西,不是说你对着视频或者书本就能照搬照学的,它更像是一种感觉,一种经验的积累,需要有人在旁边点拨,或者是在某个特殊的契机下才能豁.............
  • 回答
    这确实是一个引人深思的假设,一旦我们将维护社会秩序的重任完全交给军队或警察中的一方,整个社会运转的逻辑将发生颠覆性的改变。让我们尝试着去想象一下,如果只剩下军队,或者只剩下警察,会是什么样子。一、 如果只有军队负责维持社会秩序:想象一下,一支装备精良、纪律严明的军队,肩负起所有维护治安、处理纠纷、打.............
  • 回答
    终结者,这个科幻作品中的超级战士,一旦出现在现实战场,哪怕只是理论上的存在,也足以让任何一支常规军队感到头疼。如果美军只能依赖地面部队来对付它,这绝对是一场艰巨的挑战,需要调动的力量可不是小数目,而且还得是经过精心策划和特别武装的单位。首先,我们得明确一下“终结者”的战斗特性。假设我们讨论的是最经典.............
  • 回答
    思考一个问题:科学研究,能不能只停留在脑袋里,只做思想实验,而不去动手实践?简单来说,答案是:不行,至少不能完全是这样。当然,我知道很多人听到“科学”第一反应就是实验室、烧杯、仪器,但科学的本质可不是这些冰冷的工具,而是我们对世界的好奇心、严谨的逻辑以及不断求知的精神。那么,思想实验到底是什么呢?它.............
  • 回答
    认为迈克·泰森仅凭拳击就能称霸 UFC 的观点,本质上是一种基于对泰森个人辉煌成就和拳击运动特性的高度认可,并在此基础上进行的一种理想化和推演。这种观点通常包含以下几个层面的解读和论据,我将尽量详细地阐述:核心论据与解读:1. 泰森的绝对力量、速度和爆发力: 力量的压倒性: 泰森以其难.............
  • 回答
    澳大利亚和新西兰之所以能依靠农业走向发达国家之列,并非单一原因的堆砌,而是一个复杂而巧妙的系统性因素共同作用的结果。简单地说,它们并没有“只”靠农业,但农业在它们的发展进程中扮演了极其关键、甚至是奠基性的角色。历史的馈赠:得天独厚的自然条件首先,让我们回到历史的源头。这两个国家,尤其是澳大利亚,都是.............
  • 回答
    我想跟你聊聊关于学习网络安全并且想参加比赛这事儿。说实话,只靠自学嘛,这事儿得看你怎么学,也得看你追求的是什么程度。别的不说,单是网络安全这行当,它就像一个无底洞,永远有新东西冒出来,需要你去钻研。自学能走多远?答案是:能走挺远,但可能会有些弯路,而且上限取决于你的毅力和方法。首先,咱们得承认,现在.............
  • 回答
    这个问题非常有意思,也触及了国家发展战略的核心。如果一个国家仅仅依靠互联网和金融“立国”,而不发展制造业,我想这在当前的全球格局下,是几乎不可能实现的。当然,我也不是说互联网和金融不重要,它们当然极其重要,是现代经济的驱动力,但它们本身并不能脱离物质基础而独立存在。让我来详细解释一下我的想法,尽量避.............
  • 回答
    这是一个非常有趣且值得深入探讨的问题。如果“二次元的购买力足够强”,我认为B站理论上是有可能只靠做二次元活下去的,但要做到并且持续健康发展,需要非常精妙的运营、持续的创新以及对用户需求的深刻理解。下面我将从几个维度来详细分析:一、 “二次元购买力足够强”的定义与影响:首先,我们需要明确“二次元的购买.............
  • 回答
    关于“真正厉害的作曲家是不是不用乐器,只靠内心听觉作曲”这个问题,我想说,这是一种非常浪漫化的理解,但绝非事实的全部。虽然内心听觉能力对于任何一位作曲家来说都至关重要,但认为他们完全不依赖乐器来创作,或者说乐器只是辅助工具,这种看法未免过于片面,甚至有些误导了。咱们不妨从几个角度来细细道来:一、内心.............
  • 回答
    “全程只靠自己”这个概念,对于研究生和博士生来说,本身就有点像在问“一个人能不能把一座大山挖成一条河”。理论上,或许某个奇迹般的个体可以做到,但现实中,绝大多数情况下,这几乎是不可能的。我们先从“SCI”这个目标说起。SCI(Science Citation Index)是科学引文索引,发表一篇SC.............

本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度google,bing,sogou

© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有