长电风扇

Apipost的localhost的访问坑

2022-04-02T09:31:00Z

WSL起个服务，localhost访问嘛报错 connect ECONNREFUSED

开始以为是apipost的问题，postman也好浏览器也好都能访问，然后就apipost不行。

这边的同学用远程协助之后，我观察到apipost的log里面，localhost解析出来是127.0.0.1，但是我自己去控制台ping，解析出来是[::1] （win vista之后的默认）。

侧面说明了这127.0.0.1不是解析出来的，是代码里面写死的（code review？）。

这个么好办了，既然解析出来的 loopback address是IPV6的，那么我们直接用。

浏览器访问没问题，怀着高兴的心情去用，搞笑的是apipost不支持V6的地址，直接给我parse成http字符了。

好了只能另寻出路，查啊查，研究了一下WSL的网络（搞了n年linux现在来研究windows。。。），发现这货不是绑定到localhost的。

WSL2的虚拟机自己有个虚拟的NIC，你可以理解为localhost作为一个NAT网关，直接转发到下面设置好端口转发的wsl虚拟网卡上面。

想研究深入的自己看文档：https://docs.microsoft.com/en-us/windows/wsl/

这样么挺好，我们找到wsl自己的ip就好了，进wsl

~ ip -4 addr show eth0
5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    inet 172.17.118.219/20 brd 172.17.127.255 scope global eth0
       valid_lft forever preferred_lft forever

这样这个东西 172.17.118.219，就是wsl的ip，这个可以直接放到apipost的环境里面去用，没有任何问题。

问题解决。

但是呢，wsl这东西每次启动都会换ip，很烦，怎么办，写个powershell脚本，等每次wsl启动完了跑一下，把这ip写到一个固定的host上面就好了（所谓本地DDNS）

$hostname = "wsl"

# find ip of eth0
$ifconfig = (wsl -- ip -4 addr show eth0)
$ipPattern = "((\d+\.?){4})"
$ip = ([regex]"inet $ipPattern").Match($ifconfig).Groups[1].Value
if (-not $ip) {
    exit
}
Write-Host $ip

$hostsPath = "$env:windir/system32/drivers/etc/hosts"

$hosts = (Get-Content -Path $hostsPath -Raw -ErrorAction Ignore)
if ($null -eq $hosts) {
    $hosts = ""
}
$hosts = $hosts.Trim()

# update or add wsl ip
$find = "$ipPattern\s+$hostname"
$entry = "$ip $hostname"

if ($hosts -match $find) {
    $hosts = $hosts -replace $find, $entry
}
else {
    $hosts = "$hosts`n$entry".Trim()
}

try {
    $temp = "$hostsPath.new"
    New-Item -Path $temp -ItemType File -Force | Out-Null
    Set-Content -Path $temp $hosts

    Move-Item -Path $temp -Destination $hostsPath -Force
}
catch {
    Write-Error "cannot update wsl ip"
}

脚本抄来的，写得很不错没必要自己改，原文在这里：https://abdus.dev/posts/fixing-wsl2-localhost-access-issue/，设置自动trigger这些都有。

本来想发到apipost自己论坛去的，给我报什么非法字符，也是无奈啊

gRPC 'Error: 14 UNAVAILABLE: TCP Write failed' issue

2020-07-09T07:53:00Z

Phenomenon

最近在把公司的服务逐步从物理机部署迁移到 kubernetes 的过程中遇到了一些奇怪的问题。
其他服务都没啥问题，但是 nodejs 服务调用 grpc 服务的时候偶然会出现这种 Error，仅在 k8s 中出现:

 Error: 14 UNAVAILABLE: TCP Write failed
    at Object.exports.createStatusError (/app/node_modules/grpc/src/common.js:91:15)
    at Object.onReceiveStatus (/app/node_modules/grpc/src/client_interceptors.js:1209:28)
    at InterceptingListener._callNext (/app/node_modules/grpc/src/client_interceptors.js:568:42)
    at InterceptingListener.onReceiveStatus (/app/node_modules/grpc/src/client_interceptors.js:618:8)
    at callback (/app/node_modules/grpc/src/client_interceptors.js:847:24)
  code: 14,
  metadata: Metadata { _internal_repr: {}, flags: 0 },
  details: 'TCP Write failed'

因为的确偶然，偶然到在 UAT 测试的时候都没有遇到过，QA 也无法重现，非常头疼。
按着这个Error: 14 UNAVAILABLE: TCP Write failed去找，找来找去也都是一些说 grpc 版本的问题，看起来就不像。

Action

既然表面上看不出来，我们就打开 grpc 的 debug 模式看看 grpc 库的内部到底具体报的什么错吧。

GRPC_TRACE = all
GRPC_VERBOSITY = DEBUG

生产加上这个重新部署之后在偶然的错误里面发现了一些细节，每个Error: 14 UNAVAILABLE: TCP Write failed错误后面的 grpc 的 log 都会出现这种类型的 debug 日志:

I0709 13:20:21.758757992      16 chttp2_transport.cc:839]    W:0x39fe7b0 CLIENT [ipv4:10.98.85.83:80] state WRITING -> IDLE [finish writing]
I0709 13:20:21.758762763      16 chttp2_transport.cc:2866]   transport 0x39fe7b0 set connectivity_state=4
I0709 13:20:21.758768114      16 connectivity_state.cc:147]  SET: 0x39fea58 client_transport: READY --> SHUTDOWN [close_transport]
I0709 13:20:21.758772872      16 connectivity_state.cc:160]  NOTIFY: 0x39fea58 client_transport: 0x3645a68
I0709 13:20:21.758791048      16 tcp_custom.cc:287]          TCP 0x3772c30 shutdown why={"created":"@1594272021.758670258","description":"Delayed close due to in-progress write","file":"../deps/grpc/src/core/ext/transport/chttp2/transport/chttp2_transport.cc","file_line":593,"referenced_errors":[{"created":"@1594272021.758639866","description":"TCP Write failed","file":"../deps/grpc/src/core/lib/iomgr/tcp_uv.cc","file_line":72,"grpc_status":14,"os_error":"connection reset by peer"},{"created":"@1594272021.758743251","description":"TCP Write failed","file":"../deps/grpc/src/core/lib/iomgr/tcp_uv.cc","file_line":72,"grpc_status":14,"os_error":"broken pipe"}]}

error 里面的第一个原因是一个"os_error":"connection reset by peer"这样的 error，但是具体什么会造成这样的错误呢？

研究了一下之前所有服务的 log，发现我们的测试服完全没有Error: 14 UNAVAILABLE: TCP Write failed，出现的仅仅在 UAT 和生产服里面，而测试服和生产服最大的区别就是测试服使用的 kube-proxy 是 iptables, UAT 和生产是 ipvs.
尝试寻找了一下网上看有没有人踩过这样的坑，结果一搜就搜出来一篇相关的文章，还是中文的[Kubernetes IPVS 模式下服务间长连接通讯的优化，解决 Connection reset by peer 问题 ---- 青蛙小白][https://blog.frognew.com/2018/12/kubernetes-ipvs-long-connection-optimize.html]. 看作者的问题描述，基本判断是遇到的同样的问题。

Reason

通过阅读文章，原因锁定到了文章开头的一段话:_我们知道 gRPC 是基于 HTTP/2 协议的，gRPC 的 client 和 server 在交互时会建立多条连接，为了性能，这些连接都是长连接并且是一直保活的。这段环境中不管是客户端服务还是 gRPC 服务都被调度到各个相同配置信息的 Kubernetes 节点上，这些 k8s 节点的 keep-alive 是一致的，如果出现连接主动关闭的问题，因为从 client 到 server 经历了一层 ipvs，所以最大的可能就是 ipvs 出将连接主动断开，而 client 端还不知情_

因为我们并没有改动过 k8s 节点的net.ipv4.tcp_keepalive_time，所以经过检查我们发现系统符合出现 issue 的描述

sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_probes net.ipv4.tcp_keepalive_intvl
net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_intvl = 75

ipvsadm -l --timeout
Timeout (tcp tcpfin udp): 900 120 300

通过研究 net.ipv4.tcp_keepalive 的具体用途和设置方法之后，找到了解决方法
[How to Configure Linux TCP keepalive Setting]

Solution

net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_intvl = 30

600 + 9 * 30 = 870 < 900

尝试把net.ipv4.tcp_keepalive_time + net.ipv4.tcp_keepalive_probes * net.ipv4.tcp_keepalive_intvl改成了小于 900 的值以后，经过观察和测试，貌似出现Error: 14 UNAVAILABLE: TCP Write failed错误信息的概率变小了, 问题看起来暂时解决了一部分，准备再观察一段时间看看情况。

Solution+

观察了一晚上，发现Error: 14 UNAVAILABLE: TCP Write failed还是存在，如果理论上出现错误的原因是找正确了的，那么问题就出在解决问题的方法是否有效上面了。
在所有宿主机上面观察了net.ipv4.tcp_keepalive*的设置都是正确的

sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_probes net.ipv4.tcp_keepalive_intvl
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_intvl = 30

但是容器里面真实的情况呢？
进入容器之后运行同样的命令，发现令人沮丧的消息

sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_probes net.ipv4.tcp_keepalive_intvl
net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_intvl = 75

宿主机的sysctl设置并没有进入容器，看来 namespace 的隔离还是非常彻底的，查阅了一些资料发现，如果要设置容器内部的net.ipv4.tcp_keepalive*，会涉及到使用非安全的内核设置，需要使用priviliegedPOD 设置，不太安全[Reference][https://stackoverflow.com/questions/54552379/tcp-keepalive-time-in-docker-container/54564456#54564456].看看能不能另辟蹊径。

通过阅读grpc库的[C++文档][https://grpc.github.io/grpc/cpp/md_doc_keepalive.html]我们发现可以使用一些设置来注入grpc库，来改变库本身的对于 tcp keepalive 的频率设置。
GRPC_ARG_KEEPALIVE_TIME_MS可以设置库对于 keepalive 探针时间的频率，我们可以设置得小于等于 900 秒，同时打开设置GRPC_ARG_KEEPALIVE_PERMIT_WITHOUT_CALLS允许没有请求的时候也发送 keepalive 探针，GRPC_ARG_HTTP2_MAX_PINGS_WITHOUT_DATA设为 0 避免服务端认为过高频率的探针是恶意探针而屏蔽掉。以 nodejs 为例

const grpcClient = new GrpcService(
  process.env.GRPC_SERVER_URL,
  grpc.credentials.createInsecure(),
  {
    'grpc.keepalive_time_ms': parseInt(process.env.GRPC_ARG_KEEPALIVE_TIME_MS || '7200000'),
    'grpc.keepalive_permit_without_calls': parseInt(
      process.env.GRPC_ARG_KEEPALIVE_PERMIT_WITHOUT_CALLS || '0',
    ),
    'grpc.http2.max_pings_without_data': parseInt(
      process.env.GRPC_ARG_HTTP2_MAX_PINGS_WITHOUT_DATA || '2',
    ),
  },
);  );

又观察了一晚上发现没有任何报错了，问题解决。

鸣谢：
fangzhoutang@hotmail.com的勘误："GRPC_ARG_KEEPALIVE_TIME_MS可以设置库对于 keepalive 探针时间的频率，我们可以设置得小于等于 900 毫秒" 此处的毫秒应该为秒

The 坑 of install Kong and Konga in Docker

2019-12-05T07:53:00Z

Install Kong with PostgreSQL in docker

Create docker network

 $ docker network create kong-net

Start database (psql should be 9.6!!)

 $ docker run -d --name kong-database \
               --network=kong-net \
               -p 5432:5432 \
               -e "POSTGRES_USER=kong" \
               -e "POSTGRES_DB=kong" \
               postgres:9.6

Bootstrap data

$ docker run --rm \
     --network=kong-net \
     -e "KONG_DATABASE=postgres" \
     -e "KONG_PG_HOST=kong-database" \
     kong:latest kong migrations bootstrap

Start Kong, donot expose admin port to public! konga will handle it locally. 9000 and 9443 is for grpc.

 $ docker run -d --name kong \
     --network=kong-net \
     -e "KONG_DATABASE=postgres" \
     -e "KONG_PG_HOST=kong-database" \
     -e "KONG_PROXY_ACCESS_LOG=/dev/stdout" \
     -e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" \
     -e "KONG_PROXY_ERROR_LOG=/dev/stderr" \
     -e "KONG_ADMIN_ERROR_LOG=/dev/stderr" \
     -e "KONG_ADMIN_LISTEN=0.0.0.0:8001, 0.0.0.0:8444 ssl" \
     -e "KONG_PROXY_LISTEN=0.0.0.0:9000 http2, 0.0.0.0:9443 http2 ssl" \
     -p 80:8000 \
     -p 443:8443 \
     -p 8001:8001 \
     -p 8444:8444 \
     -p 9000:9000 \
     -p 9443:9443 \
     kong:latest

Install Konga with PostgreSQL in docker

Make sure there's not any database named konga in your psql. Use develpment env to create the db. Set KONGA_HOOK_TIMEOUT to more than 60000 to avoid hook break up.

 $ docker run --name konga \
     --network kong-net \
     -e "KONGA_HOOK_TIMEOUT=120000" \
     -e "DB_ADAPTER=postgres" \
     -e "DB_URI=postgresql://kong:@172.18.0.1:5432/konga" \
     -p 1337:1337 \
     pantsel/konga:latest

If you see this

debug: Hook:api_health_checks:process() called
debug: Hook:health_checks:process() called
debug: Hook:start-scheduled-snapshots:process() called
debug: Hook:upstream_health_checks:process() called
debug: Hook:user_events_hook:process() called
debug: Seeding User...
debug: User seed planted
debug: Seeding Kongnode...
debug: Kongnode seed planted
debug: Emailtransport seeds updated
debug: -------------------------------------------------------
debug: :: Thu Dec 05 2019 03:01:53 GMT+0000 (Coordinated Universal Time)
debug: Environment : development
debug: Host        : 0.0.0.0
debug: Port        : 1337
debug: -------------------------------------------------------

All done

Certbot for wildcard domain

2019-12-04T07:53:00Z

 $ certbot certonly --manual -d *.foo.bar -d foo.bar --server https://acme-v02.api.letsencrypt.org/directory --preferred-challenges dns

Then following the instruction add add TXT record on your domain DNS

psycopg2 macOS 安装问题

2019-04-30T03:31:00Z

备忘

报个这个错

    ld: library not found for -lssl
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    error: command 'gcc' failed with exit status 1

libssl.dylib 和 libcrypto.dylib 的版本问题

奇技淫巧

用brew安装的openssl的两个库来替代系统库

brew install openssl
env LDFLAGS="-I/usr/local/Cellar/openssl/x.x.x/include -L/usr/local/Cellar/openssl/x.x.x/lib" pip3 install psycopg2

好了

MongoDB Query 导出到文件

2017-11-03T09:31:00Z

备忘

要看一个query出来的大量信息怎么办

先要有一个js文件，来避免双引号之间的冲突，比如

var cursor = db.collection.find(); 
while(cursor.hasNext()) {
    printjson(cursor.next());
}

然后

mongo 127.0.0.1/db script.js >> output.txt

坑爹的 iOS Developer Profile

2017-05-08T09:31:00Z

是的，就是很坑爹，实在忍不了了，弄清楚了一下，然后写个备忘。

首先

在developer.apple.com/account/ios/certificate底下，有两个东西。

Certificates
Provisioning Profiles

这两个东西一个在最上面，一个在最下面。ok，首先保证你有了自己的AppID，那么点击

Certificates

你会看见你或许有一堆证书，我们不管这些，找到里面Type是iOS Development和iOS Distribution的证书，其中iOS Development是每个开发者在每台机器上能用来真机测试的证书，而iOS Distribution是用来打包app的证书并且最多只能有两个。然后我们点击

Provisioning Profiles

其中，Development的Profile可以只有一个并且包含了所有用户的iOS Development Certificate, 但是Distribution的Profile只能包含一个iOS Distribution Certificate。也就是说不管你是用AppStore的发布还是adHoc，都只能包含一个发布证书，其他的一般不会valid。

然后

我们清理掉所有不active的Profile，保证只有一个iOS Development Profile和每个iOS Distribution Certificate对应的iOS Distribution Profile。
回到我们本机，关掉Xcode

cd ~/Library/MobileDevice/Provisioning\ Profiles
rm *

打开Xcode，进入preference->account->Apple IDs->Dowload All Profiles

妈妈再也不用担心我的Profile混乱啦~

WWDC 2016 iOS10 拾遗

2016-06-14T03:24:00Z

为什么要在大家都在谈论Swift3的时候谈论ObjC? 因为Swift3还是太**（误）。

iOS10变更

根据这里iOS 9.3 to iOS 10.0 API Differences现在的文档表明，现有接口并没有什么大改变，是不可能的。根据苹果的尿性，怎么可能不大改接口呢。嗯，由于实在改的太多，不可能写完，那么就只罗列一下增加的几个主要的新特性吧。

SiriKit
Proactive Suggestions 主动推荐
Messages
User Notifications
Speech Recognition 语音转换文字
更广的色域
自定义True Tone(就是那种黄黄的夜间模式)
CallKit
App插件

那就一个一个说。

SiriKit

这次开放Siri接口估计是没多少人真正的把Siri用起来，苹果官方想增加Siri的适用面，加上的开发者接口。
按照官方的说法，Intents Framework 就是专门拿来做Siri识别响应的接口，而响应过后， Intents UI Framework就是通过系统唤起的界面使用App里功能的API了。
当然，苹果还提到了使用Siri和Map都可以达到上述效果，而且接口是通用的，也就是说实现了某个行为的响应之后，不管是Siri还是Map，只要系统识别到了是要你来干这个，那么就会调用你。
可以响应的行为：

音频视频电话
信息
接收或发出支付请求（这么吊？）
搜索图片
预定行程（滴滴和Uber的了）
健身管理

文档传送门:SiriKit Programming Guide,
Intents Framework Reference, Intents UI Framework Reference

Proactive Suggestions 主动推荐

这玩意儿其实就是加强版的SiriKit逻辑的东西，也就是像演示里面地图上出现大众点评的那样的推荐。
官方的说法是在地图，Siri，CarPlay，QuickType上会出现推荐，并且媒体播放类的还能出现在锁屏界面上，真是666。

Messages

其实就是两点，一点是你可以自己开发iMassage的表情了，还有就是开发发送到iMassage的媒体块。
当然，对于表情包来说。。为什么不去开发微信的。。毕竟Massage在国内没什么生态圈，也就是拿来收垃圾短信用。。。。而另一点更甚。。
当然，既然有，那还是放上去吧。
而且苹果都说了要建立个MessageStore专门装这些附加媒体app，想来还是有点搞头。

文档传送门:Messages Framework Reference, App Extension Programming Guide

User Notifications

好可惜的是。。貌似API还没出来，找不到UserNotifications.framework的文档呢，只能按照官方的来猜了。
基本上就是Notification类似Push的那种，带有了时间啊地点什么的特殊属性，以便于在收到通知后进行处理。而还包含的UI组件应该是对特殊类型通知的响应View，也就是官方给你个框，在里面自定义想要的东西。（苹果居心叵测想要什么都嵌入到系统里面啊简直）

语音转换文字

Speech.framework这玩意儿也没上线，但是官方贴了一段代码(注意是Swift)

let recognizer = SFSpeechRecognizer()
let request = SFSpeechURLRecognitionRequest(url: audioFileURL)
recognizer?.recognitionTask(with: request, resultHandler: { (result, error) in
     print (result?.bestTranscription.formattedString)
})

说白了也就是能在你的App里面实现把语音转换为文字的技术，就不需要自己造轮子啦，不需要自己造轮子啦，造轮子啦。

Speech ----- intent ----- Action ----- Response
   \           /\           |           / |
    \         /     \       |        /    |
     \       /         \    |    /        |
     Vocabulary         App Logic    User Interface

Mac命令行环境配置备忘（常更）

2016-06-02T09:31:00Z

Ruby gem

Mac 内建了Ruby， or (没有？)不管了。墙外忽略。
Ruby gem 更换淘宝源，不换慢到死。

$ gem sources --add https://ruby.taobao.org/ --remove https://rubygems.org/
$ gem sources -l
*** CURRENT SOURCES ***

https://ruby.taobao.org
# 请确保只有 ruby.taobao.org
$ gem install rails

ruby.taobao.org/

Home brew

虽然这货去面试被拒了，哈哈哈哈，也有今天，但是不可否认brew这个命令实在是无可替代啊.

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

接下来的很多东西都有靠他来安装，当然，如果想自己配置环境，那就忽略吧。
brew.sh/

iTerm2

$ brew cask install iTerm

好了，有了一个比较屌的终端了，嗯，跟原生的比的话，见仁见智，开心就好。
iterm2.com/

zsh

厌倦了原生bash那种无聊无色的代码么？用zsh啊。
zsh什么最好？哪里有最好，最喜欢Oh-My-Zsh。
*curl

$ sh -c "$(curl -fsSL https://raw.github.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

*wget

$ sh -c "$(wget https://raw.github.com/robbyrussell/oh-my-zsh/master/tools/install.sh -O -)"

接下来就能有了一个碉堡的可配置项了$ ~/.zshrc

.zshrc配置

Python

没有内建？没有内建？没有内建找brew。
要Pyton3？找brew。

CMake

找brew

Vim

UIImage的scale坑

2016-02-19T07:53:00Z

在做Play+的图片剪切的时候遇到个神坑的问题，同样的剪切数据，同样样子的图，对本地图片的剪切效果就是跟对网络图片的剪切效果不一样，而且大概是iOS9.1左右时候出现的问题。简直百思不得其解，但是这种问题又不算小问题，不可能搁置一边，使劲跟了跟，跟到一个UIImage的神坑。
UIImage有个属性叫做scale(废话)，官方文档给的描述是这样的:

@property(nonatomic, readonly) CGFloat scale

Discussion
If you load an image from a file whose name includes the @2x modifier, the scale is set to 2.0. You can also specify an explicit scale factor when initializing an image from a Core Graphics image. All other images are assumed to have a scale factor of 1.0.

If you multiply the logical size of the image (stored in the size property) by the value in this property, you get the dimensions of the image in pixels.

也就是说scale的来源有你从文件名读取的图片名字带@nx的那个n。要么就是从CGImage转换来的自己写的scale。也就是，这个方法：

+ (UIImage *)imageWithCGImage:(CGImageRef)cgImage scale:(CGFloat)scale orientation:(UIImageOrientation)orientation NS_AVAILABLE_IOS(4_0);

仔细看了看文件，跟scale有关的还有这几个方法：

+ (nullable UIImage *)imageWithData:(NSData *)data scale:(CGFloat)scale NS_AVAILABLE_IOS(6_0);
+ (UIImage *)imageWithCIImage:(CIImage *)ciImage scale:(CGFloat)scale orientation:(UIImageOrientation)orientation NS_AVAILABLE_IOS(6_0);
- (nullable instancetype)initWithData:(NSData *)data scale:(CGFloat)scale NS_AVAILABLE_IOS(6_0);
- (instancetype)initWithCGImage:(CGImageRef)cgImage scale:(CGFloat)scale orientation:(UIImageOrientation)orientation NS_AVAILABLE_IOS(4_0);
- (instancetype)initWithCIImage:(CIImage *)ciImage scale:(CGFloat)scale orientation:(UIImageOrientation)orientation NS_AVAILABLE_IOS(6_0);

然后，然后在并没有使用这几个跟scale相关方法，奇怪的事情发生了。
从手机相册直接导入的图片的scale如下

就是这张UIImage，上传到7牛服务器，再用SDWebImage下载成为一个新的UIImage的时候，scale变成了这样

这就是导致同样的图片，同样的剪切，但是剪切出来的图片区域不一样的原因了。
但是这个问题为什么会产生呢。