Xiphap

Xiphap 查看完整档案

填写现居城市  |  填写毕业院校  |  填写所在公司/组织填写个人主网站
编辑

┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┫ ┆ ┣┼┼┼┼┼┼┼┼┼┼┼┼┼┼
┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┫ ┆ ┣┼┼┤Art├┼┼┼┼┼┼┼
┻┻┻┻┻┻┻┻┻┻┻┻┻┻┻┻┻┻┻┻┻┻╯ ┆ ╰┻┻┻┻┻┻┻┻┻┻┻┻┻
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
┳┳┳┳┳┳┳┳┳┳┳┳┳┳┳┳┳┳┳┳┳┳╮ ┆ ╭┳┳┳┳┳┳┳┳┳┳┳┳┳
┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┫ ┆ ┣┼┼┼┼┼┼┼┼┼┼┼┼┼┼
┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┤Code├┼┼┫ ┆ ┣┼┼┼┼┼┼┼┼┼┼┼┼┼┼
┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┼┫ ┆ ┣┼┼┼┼┼┼┼┼┼┼┼┼┼┼

个人动态

Xiphap 赞了文章 · 2020-08-06

思否开源项目推介丨Remax:使用 React 构建跨平台小程序

clipboard.png

开源项目名称:Remax
开源项目负责人:@yesmeck
开源项目简介:使用 React 构建跨平台小程序
开源项目类型:团队开源项目
项目创建时间:2019 年
GitHub 数据:3K Star,211 Fork
GitHub 地址:http://github.com/remaxjs/remax

项目介绍

clipboard.png

Remax 将 React 运行在小程序环境中,让你可以使用完整的 React 进行小程序开发。

  • 真正的 React - 不同于静态编译的方案,在 Remax 中使用 React 没有任何限制,包括 React Hooks。你可以把 Remax 理解为针对小程序的 React Native。
  • 多端支持 - 使用 Remax 把代码转换到多个小程序平台。
  • TypeScript - 完整的 TypeScript 支持,给你满满的安全感。

Remax 的实现原理

clipboard.png

Remax 本身分为两个部分,remaxreamx-cliremax 提供运行时,remax-cli 提供构建功能。其中Remax 的运行时本质是一个通过 react-reconciler 实现的一个小程序端的渲染器。

Remax 把 React 和 ReactReconciler 运行在小程序的逻辑层中,并通过 Remax 把生成的「虚拟 DOM」渲染到视图层。从而做到了使用真正的 React 去构建小程序。

且受 CSS 属性名前缀的启发,Remax 团队重新设计了 Remax 的跨平台方案。 团队非常克制地选取了 9 个基础组件,统一了他们之间非平台私有的属性,并且以属性名前缀的方式来支持各个平台私有的特性。Remax 团队希望开发者在做跨平台开发时能清楚地意识到使用者写下的这行代码只会在特定的平台上生效。

对了,Remax 默认支持 TypeScript 开发,提供完整的组件和 API 类型定义,为你的项目保驾护航。

思否推荐

内容介绍里有一个点没有提到,Remax 是蚂蚁金服前端团队开源的项目,能够很好保证项目的质量。Remax 口号是使用真正的 React 构建跨平台小程序,相比 Taro 静态编译的方式实现的复杂度,Remax 更像是新的 React 渲染器,技术层面要简单很多。

Remax 还原 React 的开发体验,默认支持 TypeScript 开发、多端支持也是基础特性。借用开发者的话:把 React 运行在小程序中可以带来非常大的想象力。小程序本身可以说是一种创新,它把应用分为两层来提高视图层的渲染速度,但是微信从一开始就选择使用私有且落后(起码目前看来是落后的)的技术方案来定义小程序,而后面的追随者为了吸引开发者亦使用了跟微信小程序类似的设计。Remax 希望能打破这个局面,通过开放的生态为开发者带来全新的小程序开发体验。


clipboard.png

该项目已入选「SFOSSP - 思否开源项目支持计划」,我们希望借助社区的资源对开源项目进行相关的宣传推广,并作为一个长期项目助力开源事业的发展,与广大开发者共建开源新生态。

有意向的开源项目负责人或团队成员,可通过邮箱提供相应的信息(开源项目地址、项目介绍、团队介绍、联系方式等),以便提升交流的效率。

联系邮箱:pr@segmentfault.com

clipboard.png

查看原文

赞 22 收藏 7 评论 4

Xiphap 赞了回答 · 2018-09-10

解决Python socket 搭建的服务器如何返回 JSON 数据给到浏览器

如果后端是 socket,想要返回信息给前端,那你不能直接返回 json 数据,因为你需要构造 http 报文的响应头,然后再把 json 数据放进去,与其这样,还不如后端直接起个简易的 httpserver,这样就真的只需要处理 json 了

关注 3 回答 3

Xiphap 提出了问题 · 2018-09-08

解决Python socket 搭建的服务器如何返回 JSON 数据给到浏览器

用 Python socket 搭建的后端服务器,浏览器前端用 AJAX 访问这个服务器下的 xx.py,该怎么返回 JSON 数据给前端,方便前端获取 JSON 数据?
请知道的大神帮忙解惑,谢谢!


下面是代码:

import socket
server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.bind(('127.0.0.1', 8080))
server.listen(50)
while True:

data, addr = server.accept()
info = b'{"id":"test", "psw":"123"}'

buffer = data.recv(1024)
data.send("HTTP/1.1 200 OK\r\nContent-type: text/html\r\n\r\n"+info)
data.close()

问题已解决

在答友@Lin_R的提示下,自己尝试让 socket 以“http 报文响应头”+ JSON 格式内容返回给浏览器,能够正确拿到 JSON 数据。之前不能拿到是因为 AJAX 调用的 HTTP 主域名是本机域名(127.0.0.1),而服务器的域名地址是(192.168..),这就导致了“跨域问题”,浏览器不允许 AJAX 成功调用 JSON 的问题。PS:有兴趣可以查查“AJAX跨域”相关问题,希望能帮到跟我遇到同样问题的伙伴。
就此结疑。

关注 3 回答 3

Xiphap 赞了文章 · 2018-08-29

合并HTTP请求 vs 并行HTTP请求,到底谁更快?

面试时,经常会问候选人一个问题:如何提高网页性能?

有些基础的人都会提到这么一条:减少/合并HTTP请求。

继续问:浏览器不是可以并行下载资源吗?将多个资源合并成一个资源,只使用一个HTTP请求下载,难道要比用多个HTTP请求并行下载没有合并过的多个资源速度更快?

候选人:……(至今,还没有遇到让我满意的回答)

减少HTTP请求,是雅虎前端性能优化35条军规的第1条,2006年雅虎提出了这35条军规,从那以后,就深深地影响到了一批又一批的前端开发者,即使在12年后的今天,影响力依旧不减…..

但是,雅虎军规中还有1条是:拆分资源以最大化利用浏览器并行下载的能力。现在问题就来了,减少HTTP请求,但网页所需的资源并不能减少(否则网页就不再是之前的网页了),所以减少HTTP请求,主要是通过合并资源来实现的,一边是建议合并资源,一边是建议拆分资源,显然是有冲突的地方,那么到底该怎么做呢?网上有些文章也讨论过这个问题,但大多是停留在想当然的理论分析上,而且忽略了TCP传输机制的影响。今天,老干部就带大家一起用实验+理论,仔细探讨下这个问题。

HTTP请求过程

一个HTTP请求的主要过程是:

DNS解析(T1) -> 建立TCP连接(T2) -> 发送请求(T3) -> 等待服务器返回首字节(TTFB)(T4) -> 接收数据(T5)。

如下图所示,是Chrome Devtools中显示的一个HTTP请求,显示了HTTP请求的主要阶段,注意,Queueing阶段是请求在浏览器队列中的排队时间,并不计入HTTP请求时间

图片描述

从这个过程中,可以看出如果合并N个HTTP请求为1个,可以节省(N-1)* (T1+T2+T3+T4) 的时间。

但实际场景并没有这么理想,上面的分析存在几个漏洞:

  1. 浏览器会缓存DNS信息,因此不是每次请求都需要DNS解析。
  2. HTTP 1.1 keep-alive的特性,使HTTP请求可以复用已有TCP连接,所以并不是每个HTTP请求都需要建立新的TCP连接。
  3. 浏览器可以并行发送多个HTTP请求,同样可能影响到资源的下载时间,而上面的分析显然只是基于同一时刻只有1个HTTP请求的场景。

实验论证

我们来做4组实验,对比一个HTTP请求加载合并后的资源所需时间,和多个HTTP请求并行加载拆分的资源所需时间。每组实验所用资源的体积大小有显著差异。

实验环境:

服务器:阿里云ECS 1核 2GB内存 带宽1M

Web服务器:Nginx (未启用Gzip)

Chrome v66 隐身模式,禁用缓存

Client 网络:wifi 带宽20M

实验代码地址:https://github.com/xuchaobei/...

实验 1

测试文件:large1.css、large2.css … large6.css,每个文件141K;large-6in1.css,由前面6个css文件合并而成,大小为846K。parallel-large.html引用large1.css、large2.css … large6.css, combined-large.html引用large-6in1.css,代码如下:

// parallel-large.html
<!DOCTYPE html>
<html>

  <head>
    <meta charset="utf-8" />
    <title>Parallel Large</title>
    <link rel="stylesheet" type="text/css" media="screen" href="large1.css" />
    <link rel="stylesheet" type="text/css" media="screen" href="large2.css" />
    <link rel="stylesheet" type="text/css" media="screen" href="large3.css" />
    <link rel="stylesheet" type="text/css" media="screen" href="large4.css" />
    <link rel="stylesheet" type="text/css" media="screen" href="large5.css" />
    <link rel="stylesheet" type="text/css" media="screen" href="large6.css" />
  </head>

  <body>
    Hello, world!
  </body>

</html>
// combined-large.html
<!DOCTYPE html>
<html>

  <head>
    <meta charset="utf-8" />
    <title>Combined Large</title>
    <link rel="stylesheet" type="text/css" media="screen" href="large-6in1.css" />
  </head>

  <body>
    Hello, world!
  </body>

</html>

分别刷新2个页面各10次,利用Devtools 的Network计算CSS资源加载的平均时间。

注意事项:

  1. large1.css、large2.css … large6.css的加载时间,计算方式为从第一个资源的HTTP请求发送开始,到6个文件都下载完成的时间,如图2红色框内的时间。
  2. 两个html页面不能同时加载,否则带宽为两个页面所共享,会影响测试结果。需要等待一个页面加载完毕后,再手动刷新加载另外一个页面。
  3. 页面两次刷新时间间隔在1分钟以上 ,以避免HTTP 1.1 连接复用对实验的影响。

图片描述

实验结果如下:

large-6in1.csslarge1.css、large2.css … large6.css
平均时间(s)5.525.3

我们再把large1.css、large2.css … large6.css合并为3个资源large-2in1a.css、large-2in1b.css、large-2in1c.css,每个资源282K,在combined-large-1.html中引用这3个资源:

// combined-large-1.html
<!DOCTYPE html>
<html>

  <head>
    <meta charset="utf-8" />
    <title>Parallel Large 1</title>
    <link rel="stylesheet" type="text/css" media="screen" href="large-2in1a.css" />
    <link rel="stylesheet" type="text/css" media="screen" href="large-2in1b.css" />
    <link rel="stylesheet" type="text/css" media="screen" href="large-2in1c.css" />
  </head>

  <body>
    Hello, world!
  </body>

</html>

测试10次,平均加载时间为5.20s。

汇总实验结果如下:

large-6in1.csslarge1.css、large2.css … large6.csslarge-2in1a.css、... large-2in1c.css
平均时间(s)5.525.305.20

从实验1结果可以看出,合并资源和拆分资源对于资源的总加载时间没有显著影响。实验中耗时最少的是拆分成3个资源的情况(5.2s),耗时最多的是合并成一个资源的情况(5.52s),但两者也只不过相差6%。考虑到实验环境具有一定随机性,以及实验重复次数只有10次,这个时间差并不能表征3种场景有明显的时间差异性。

实验 2

继续增加css文件大小。

测试文件:xlarge1.css、xlarge2.css 、xlarge3.css,每个文件1.7M;xlarge-3in1.css,由前面3个css文件合并而成,大小为5.1M。parallel-xlarge.html引用xlarge1.css、xlarge2.css 、xlarge3.css, combined-xlarge.html引用xlarge-3in1.css。

测试过程同上,实验结果如下:

xlarge-3in1.cssxlarge1.css、xlarge2.css、xlarge3.css
平均时间(s)37.7236.88

这组实验的时间差只有2%,更小了,所以更无法说明合并资源和拆分资源的总加载时间有明显差异性。

实际上,理想情况下,随着资源体积变大,两种资源加载方式所需时间将趋于相同。

从理论上解释,因为HTTP的传输通道是基于TCP连接的,而TCP连接具有慢启动的特性,刚开始时并没有充分利用网络带宽,经过慢启动过程后,逐渐占满可利用的带宽。对于大资源而言,带宽总是会被充分利用的,所以带宽是瓶颈,即使使用更多的TCP连接,也不能带来速度的提升。资源越大,慢启动所占总的下载时间的比例就越小,绝大部分时间,带宽都是被充分利用的,总数据量相同(拆分资源导致的额外Header在这种情况下完全可以忽略不计),带宽相同,传输时间当然也相同。

实验 3

减小css文件大小。

测试文件:medium1.css、medium2.css … medium6.css,每个文件9.4K;medium-6in1.css,由前面6个css文件合并而成,大小为56.4K。parallel-medium.html引用medium1.css、medium2.css … medium6.css, combined-medium.html 引用 medium-6in1.css。

实验结果如下:

medium-6in1.cssmedium1.css、medium2.css … medium6.css
平均时间(ms)34.8746.24

注意单位变成ms

实验3的时间差是33%,虽然数值上只差12ms。先不多分析,继续看实验4。

实验 4

继续减小css文件大小,至几十字节级别。

测试文件:small1.css、small2.css … small6.css,每个文件28B;small-6in1.css,由前面6个css文件合并而成,大小为173B。parallel-medium.html引用small1.css、small2.css … small6.css, combined-medium.html 引用 small-6in1.css。

实验结果如下:

small-6in1.csssmall1.css、small2.css … small6.css
平均时间(ms)20.3335

实验4的时间差是72%。

根据实验3和实验4,发现当资源体积很小时,合并资源和拆分资源的加载时间有了比较明显的差异。图3和图4是实验4中的某次测试结果的截图,当资源体积很小时,数据的下载时间(图中水平柱的蓝色部分所示)占总时间的比例就很小了,这时候影响资源加载时间的关键就是DNS解析(T1) 、 TCP连接建立(T2) 、发送请求(T3) 和等待服务器返回首字节(TTFB)(T4) 。但同时建立多个HTTP连接本身就存在额外的资源消耗,每个HTTP的DNS查询时间、TCP连接的建立时间等也存在一定的随机性,这就导致并发请求资源时,出现某个HTTP耗时明显增加的可能性变大。如图3所示,small1.css加载时间最短(16ms),small5.css加载时间最长(32ms),两者相差了1倍,但计算时间是以所有资源都加载完成为准,这种情况下,同时使用多个HTTP请求就会导致更大的时间不均匀性和不确定性,表现结果就是往往要比使用一个HTTP请求加载合并后的资源慢。

图片描述

图片描述

更复杂的情况

对于小文件一定是合并资源更快吗?

其实未必,在一些情况下,合并小文件反而有可能明显增加资源加载时间。

再说些理论的东西。为了提高传输效率,TCP通道上,并不是发送方每发送一个数据包,都要等到收到接收方的确认应答(ACK)后,再发送下一个报文。TCP引入了”窗口“的概念,窗口大小指无需等待确认应答而可以继续发送数据的最大值,例如窗口大小是4个MSS(Maximum Segment Size,TCP数据包每次能够传输的最大数据分段),表示当前可以连续发送4个报文段,而不需要等待接收方的确认信号,也就是说,在1次网络往返(round-trip)中完成了4个报文段的传输。如下图所示(MSS为1,窗口大小为4),1 - 4000 数据是连续发送的,并没有等待确认应答,同样的,4001 - 8000也是连续发送的。请注意,这只是理想情况下的示意图,实际情况要比这里更复杂。

图片描述

在慢启动阶段,TCP维护一个拥塞窗口变量,这个阶段窗口的大小就等于拥塞窗口,慢启动阶段,随着每次网络往返,拥塞窗口的大小就会翻一倍,例如,假设拥塞窗口的初始大小为1,拥塞窗口的大小变化为:1,2,4,8……。如下图所示。

图片描述

实际网络中,拥塞窗口的初始值一般是10,所以拥塞窗口的大小变化为:10,20,40 ... ,MSS的值取决于网络拓扑结构和硬件设备,以太网中MSS值一般是1460字节,按每个报文段传输的数据大小都等于MSS计算(实际情况可以小于MSS值),经过第1次网络往返后,传输的最大数据为14.6K,第2次后,为(10+20) 1.46 = 43.8K, 第3次后,为(10+20+40) 1.46 = 102.2K。

根据上面的理论介绍,实验4中,不管是合并资源,还是拆分资源,都是在1次网络往返中传输完成。但实验3,拆分后的资源大小为9.4K,可以在1次网络往返中传输完成,而合并后的资源大小为56.4K,需要3次网络往返才能传输完成,如果网络延时很大(例如1s),带宽又不是瓶颈,多了两次网络往返将导致耗时增加1s,这时候合并资源就可能得不偿失了。实验3并没有产生这个结果的原因是,实验中网络延时是10ms左右,由于数值太小而没有对结果产生明显影响。

总结

对于大资源,是否合并对于加载时间没有明显影响,但拆分资源可以更好的利用浏览器缓存,不会因为某个资源的更新导致所有资源缓存失效,而资源合并后,任一资源的更新都会导致整体资源的缓存失效。另外还可以利用域名分片技术,将资源拆分部署到不同域名下,既可以分散服务器的压力,又可以降低网络抖动带来的影响。

对于小资源,合并资源往往具有更快的加载速度,但在网络带宽状况良好的情况下,因为提升的时间单位以ms计量,收益可以忽略。如果网络延迟很大,服务器响应速度又慢,则可以带来一定收益,但在高延迟的网络场景下,又要注意合并资源后可能带来网络往返次数的增加,进而影响到加载时间。

其实,看到这里,是合是分已经不重要了,重要的是我们要知道合分背后的原理是什么,和业务场景是怎样的。

查看原文

赞 366 收藏 266 评论 19

Xiphap 赞了文章 · 2018-08-21

普通网站防暴力破解的新设计

前端防暴力破解的一个设计

Demo 地址

https://github.com/GitHub-Laz...

描述

传统的防范暴力破解的方法是在前端登录页面增加验证码, 虽然能有一定程度效果, 但是用户也跟着遭罪, 验证码越复杂, 用户登录的失败率越高

于是最近我想了一个新的设计, 前端在登录时采用解密的方式获取密钥, 把密钥与表单以前发往后端, 用密钥来代替验证码

具体细节如下

设计

  • 用户在登录页面输完用户名密码, 点击登录
  • js 向后端请求密文
  • 后端生成一个随机字符串和一个指定范围内的随机数
  • 正向拼接 随机字符串 和 随机字符串随机数的加密 得到密文rstr+MD5(rstr+rint)
  • 反向拼接 得到 密钥 MD5(rint+rstr)
    randomString = Utils.getUUID();
    randomNumber = Utils.randomInt(range);
    privateText =  randomString + Utils.md5(randomString+randomNumber);
    privateKey= Utils.md5(randomNumber+randomString);
  • 将密文传给前端
  • 前端通过循环破解随机数
    let randomString = result.substring(0, 32)
    let valueString = result.substring(32)
    let answerString
    for (let i = 0; i < range; i++) {
        let s = crypto.createHash("md5").update(randomString + i).digest('hex')
        if (s == valueString) {
            answerString = crypto.createHash("md5").update(i + randomString).digest('hex')
            break
        }
    }
  • 把得到的密钥和表单一起传个后端
  • 后端验证密钥的真假

测试

经过测试10000次内md5加密前端用时不超过300ms, 用户察觉不到, 但是暴力破解的难道确增加了几千倍, 这意味这本来一个小时能破解的网站, 现在可能要一年才能破解

优势

  • 整个流程对后端带来的压力几乎为0
  • 用户无需输入验证码
  • 前端延时极小(对人来说)
  • 对暴力破解影响极大
  • 只需添加部分代码, 无需更改现有的代码
  • 条件可控, 随机数的范围完全由后端决定
欢迎关注我的博客公众号
图片描述
查看原文

赞 193 收藏 149 评论 24

Xiphap 赞了问题 · 2018-08-09

socket类服务端如何防止被ddos攻击?

比如说我用socket,或者swoole的websocket服务器编写一个游戏服务端,但是客户端可以通过无限发包的方式来攻击我的游戏服务端,导致服务端崩溃,请问目前有什么比较好的方案可以防止这类ddos,cc攻击?(像网上各种cdn都只能防HTTP类型的请求攻击)

听别人说有硬件防火墙,但是如果我用阿里云腾讯云之类的服务器搭建服务端的话就没办法安硬件防火墙啊,有软件可以做类似的防御吗?


(不知道这里的朋友是否玩过英雄联盟或者穿越火线,这些游戏曾经都有各种炸房外挂,原理其实也是向他们的服务端发送大量垃圾数据包,或者超出正常频率发送含有奇怪逻辑的数据包,导致同一个房间内的其他订阅了该游戏服务端某种消息的玩家也会短时间大量收到这些数据包从而让客户端崩溃掉线,可见连腾讯游戏之前都对这类攻击没什么防范措施)

关注 5 回答 3

Xiphap 提出了问题 · 2018-08-02

Python 模块 socket 如何在收到空数据时停止?

问题

Python 的模块 socket 用 ecv() 不断监听客户端发来的请求数据,包括空字符串 b'' ,怎么识别出空的请求并阻止?

源码

服务器端:

import socket
server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.bind(('127.0.0.1', 8080))
server.listen(50)
while True:
    data, addr = server.accept()
    info = b'OK'
    while True:
        buffer = data.recv(2)    # 如果客户端发送 b'',进程将卡在这里,下面无法执行
        if buffer == b'':
            info = b'Bad request'
            break
    data.send(info)
    data.close()

客户端:

import socket

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.1', 8080))
data = b''
s.send(data)
data_get = s.recv(1024)    # 进程会卡在这里,收不到响应
s.close()

关注 5 回答 4

Xiphap 赞了回答 · 2018-07-30

解决Python 如何动态调用py文件

谢邀,这个动态引入是希望能够实现传入一个字符串如 "os" ,能够帮你实现 import os 的形式吧,那么,__import__ 能够完成你想要的:

图片描述

关注 3 回答 2

Xiphap 提出了问题 · 2018-07-30

解决Python 如何动态调用py文件

目的

能够动态地调用不同py文件,传入参数并获得返回参数。下面是想象中的实现方法。

a.py :

path_file = 'b.py'    # 动态指定py文件位置
para_in = 123
para_out = xxx(path_file,para_in)    # 该函数是path_file(这里是b.py)文件里的函数,传入参数,返回参数赋给para_out

b.py :

def xxx(para):
    执行方法(例: para += 1)
    return para

已知方法

已经搜寻过能够实现类似的方法有几个,但都不够理想:

  • import

    下面是用 import 实现「目的」描述的方法,但不能实现动态地加载py文件,且 Python PEP8 规范不建议 import 放在执行内容中:
    a.py :

    import b
    para_in = 123
    para_out = b.xxx(para_in)

    b.py :

      def xxx(para):
      执行方法(例: para += 1)
      return para
  • exec()

    下面是用 exec() 实现「目的」描述的方法,但似乎不太“干净”,Pycharm 会警告在调用py文件的方法前,事先声明和py文件中同样函数名的函数(执行方法可以随意写,因为会被py中同名函数覆盖):
    a.py :

    def xxx(para):
      return
    path_file = 'b.py'
    para_in = 123
    
    with open(path_file, 'r') as file:
      exec(file.read())
      para_out = xxx(para_in)

    b.py :

    def xxx(para):
      执行方法(例: para += 1)
      return para

问题

上面的方法虽然能实现「目的」,但似乎不够理想。所以问题是,是否有更好的办法实现「目的」?

关注 3 回答 2

认证与成就

  • 获得 22 次点赞
  • 获得 21 枚徽章 获得 0 枚金徽章, 获得 5 枚银徽章, 获得 16 枚铜徽章

擅长技能
编辑

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 2018-03-22
个人主页被 584 人浏览