为了减轻服务器负担，不少站长会选择将图片托管在图床上。本文整理了一些好用的免费图床服务（文末也列出了部分收费图床）

2025.05.04更新:

五一期间更新，追加图床，自测都是可用的图床。

1. 敖武的图床 支持免费使用，支持多种格式

原推荐图床：

原文来自网络，我进行了有效性的验证，已删除无效图床，并会进行长期更新维护，方便大家使用。

1.微博图床

堪称国内图床的中流砥柱，很多站长都在用。各种插件和在线上传都层出不穷，使用起来很方便。

• 速度：国内国外都非常快

• CDN：国内分别接入使用了蓝汛、网宿、阿里云 CDN、加速乐等，在国外使用了 Akamai CDN、http://Tierra.Net 的 CDN 等

• HTTPS：支持（不完全支持 HTTP2，得看你被解析到了哪个服务商的节点）

• 域名：

• ww1.sinaimg.cnww2.sinaimg.cnww3.sinaimg.cnww4.sinaimg.cn

• wx1.sinaimg.cnwx2.sinaimg.cnwx3.sinaimg.cnwx4.sinaimg.cn

• ws1.sinaimg.cnws2.sinaimg.cnws3.sinaimg.cnws4.sinaimg.cn

• 等等等等。。。

• 上传地址

• Chrome 插件

2.sm.ms 图床

土豪兽兽建的图床，2015 年开始正式运营。

• 速度：现在估计是被滥用了没那么快了 烧风购买了更多节点、修改了服务架构，现在全球速度还是不错的。

• CDN：烧风自建的 CDN，有香港阿里云、DigitalOcean 欧洲和 Linode 北美等节点

• HTTPS：HTTP 会被 301 跳转 HTTPS（支持 HTTP2）

• 域名：ooo.0o0.oooi.loli.net

• 上传地址

支持 API 操作，图片存储非常可靠，V2EX 钦点的图床。iOS 和 Android 应用 即将开发完毕已经分别上架 iTunes 和 Play Store，甚至有第三方做的 Telegram Bot。在众多公共图床中最看好它和 imgur。

3.ooxx

V2EX 上找到的一家老牌图床，2013 年就开始运营了，不过 2017 年年初才在 V2EX 上发帖。

• 速度：CloudFlare 的网络特点，大家都懂

• CDN：CloudFlare

• HTTPS：支持（支持 HTTP2）

• 域名：i.ooxx.ooo

• 上传地址

V2EX 上的介绍说最早是为了收集一些网络图片作为大数据分析和机器学习用的，所以借用机器闲置的带宽搞了这个图床。运营了四年，看起来还会继续运营下去。

4.PostImage

• 速度：国外速度杠杠的，国内别被墙就好

• CDN：AdvancedHosted CDN

• HTTPS：支持

• 域名：s1.postimg.orgs2.postimg.org 等。

• 上传地址

PostImage 图床的介绍说是为了方便用户在 Facebook 和 Twitter 上传图。这个图床用的 CDN 服务商不太有名。

5. http://6.UPLOAD.CC

• 速度：看下面一条用的 CDN

• CDN：CloudFlare

• HTTPS：支持

• 域名：upload.cc。

• 上传地址

这个图床是香港人开的，TOS 写的挺详细的。提供了 Android 版 APP（Google Play 上可下载），还提供有 Chrome 和 Firefox 的插件，挺方便的。

6.小贱贱图床

• 速度：一般般~获取一个简单的外链，图床用的是微博空间，速度很快，但是图片清晰度会变低。

• 每日可以上传图片20张，上传后可以

• 上传地址

7.聚合图床

• 速度：集合多家图床，速度还是可以的~

• 上传时一张图片会分发至多个图床，同时图片会保存在本站服务器上

• 上传地址

8.偶流社区图床

• 免注册，有一定历史，比较可靠

• 限制：图片最大10M，不定期会清理垃圾文件

• 上传地址

9.路过图床

• 支持免注册上传图片，永久存储，支持HTTPS加密访问和调用图片，提供多种图片链接格式

• 限制：最大10M

• 上传地址

10.极简图床

• 主要提供图片上传和管理界面，需要用户自己设置微博、七牛云或者阿里云OSS信息

• 目前站点维护，原因不详

• 上传地址

11.Imgbb

• 最大 16 MB 图片大小. 直接的源图片链接, BBCode代码和HTML缩略图显示

• 上传地址

以下为收费（部分包含使用期限）

1.又拍云

• 注册认证后有10G永久免费空间，每月15G的HTTP和HTTPS流量，提供两款可以免费续期的SSL证书，不过用户需要加入又拍云联盟（即在网站底部添加又拍云logo及官网链接）

• 图片上传限制：无

• 上传地址

2.腾讯云

• 可以使用六个月的免费存储容量、免费请求和免费流量

• 限制：时间、流量、空间大小均有限制

• 上传地址

3.阿里云OSS

• 海量、安全、低成本、高可靠的云存储服务，提供99.999999999%的数据可靠性。使用RESTful API 可以在互联网任何位置存储和访问，容量和处理能力弹性扩展，多种存储类型供选择全面优化存储成本。

• 不一定存储图片，文件都是ok的，不过扣量很严重，以为这个网站之前就是用的oss。

• 官网

原来页面encodeURIComponent编码URL传参数，在接收页面不需要手动给option decodeURIComponent解码 。

关于iOS应用提交App Store提示SDK版本不兼容的解决方案（ITMS-90725错误）

问题现象：
使用HBuilder开发的UniApp项目通过提交后，提示：
"This app was built with the iOS 17.5 SDK. All iOS and iPadOS apps must be built with the iOS 18 SDK or later..."

或者使用蛋壳Uploader 上传报错, 验证失败:

Validation failed (409) SDK version issue. This app was built with the iOS 17.5 SDK. All iOS and iPadOS apps must be built with the iOS 18 SDK or later, included in Xcode 16 or later, in order to be uploaded to App Store Connect or submitted for distribution

根本原因：
2024年6月苹果强制要求所有新提交应用必须使用Xcode 16（含iOS 18 SDK）构建。当前开发环境使用的SDK版本已不符合最新要求。

解决方案：
请按以下步骤升级开发环境：

1. 升级基础开发工具

   • 安装最新Xcode 16（通过App Store或开发者官网下载）
   • 确保MacOS系统版本符合Xcode 16要求（建议Ventura 13.5或更高）

2. 更新HBuilder开发环境

   • 打开HBuilderX
   • 导航至【帮助】→【检查更新】安装最新正式版（推荐3.9.10+）
   • 重启IDE使更新生效

3. 更新UniApp依赖链
   在项目根目录执行：

   npx @dcloudio/uvm@latest

   该命令将自动更新以下关键组件：

   • uni-app编译器至最新稳定版
   • iOS平台特定依赖
   • 原生插件兼容层

4. 重建生产包

   • 清理项目缓存：菜单【运行】→【清理项目缓存】
   • 重新生成iOS证书文件（建议更新为2024年签发的证书）
   • 使用【发行】→【原生App-云打包】生成新二进制文件

验证要点：
完成上述步骤后，通过HBuilder控制台检查构建日志，确认包含以下信息：

Using iOS SDK version: 18.0+
Xcode version: 16.0+

补充说明：
若使用自定义原生插件，需同步更新插件代码至适配iOS 18的版本。建议在真机调试阶段使用Xcode 16连接设备进行兼容性验证，避免因API变更导致的运行时异常。

更多讨论:

https://ask.dcloud.net.cn/article/41555

最近使用了uni-automator对小程序项目进行自动化测试
由于官方文档比较简单，并没有罗列一些常见问题，再加上本身用的人就少，可以说踩尽了坑。

问题一：

问题二：

所有的测试用例只有第一条能执行成功，后续用例结果都会变成 [object HTMLElement]

并且开发者工具中会抛出大片错误，并且点击页面元素没有交互响应。

Converting circular structure to JSON  
--> starting at object with constructor 'l'  
| property 'parentNode' -> object with constructor 'd'  
| property 'childNodes' -> object with constructor 'Array'  
--- index 0 closes the circle(env: macOS,mp,1.06.2412050; lib: 3.7.10)>

也是一个百思不得其解的问题，又耽误了我两天，最后发现是开发者工具的版本问题，当时用的是1.06.2503281，后来卸载安装了1.06.2409140是可以的。

后续遇到其他问题再更新....

2025跨端ai实战-基于uniapp+vue3对接deepseek-v3 api搭建多端ai流式输出模板。
支持编译运行到web+小程序+App端，支持暗黑+亮色主题模式、代码高亮、上下文多轮对话、本地存储会话等功能。

采用技术

• 编码工具：HbuilderX 4.57
• 技术框架：Uniapp+Vue3+Pinia2+Vite5.x
• 大模型框架：DeepSeek-V3
• UI组件库：uni-ui+uv-ui
• 高亮插件：highlight.js
• markdown解析：ua-markdown
• 本地缓存：pinia-plugin-unistorage
• 运行编译：H5+小程序+APP端

功能亮点

1. 支持编译到H5/小程序端/App端
2. 支持各种代码高亮、上下文多轮对话/本地会话存储
3. 支持代码块横向滚动、行号、代码复制功能(h5/app端)
4. 支持图片渲染宽度100%、图片预览功能(h5/app端)
5. 支持链接跳转功能(h5/app端)
6. 修复小程序端表格边框线及各类标签选择器样式失效

目前该项目已经更新到我的原创作品集，感谢支持鼓励！
uniapp+deepseek+vue3跨端AI流式输出对话模板

想要了解更多的技术实现细节可以去看看下面这篇分享文章。
Uniapp-DeepSeek跨三端AI助手|uniapp+vue3+deepseek-v3流式ai聊天模板

'''### 如何保护 iOS App 的最后一道防线：那些你可能忽略的混淆技巧

如果你曾认真反编译过别人的 .ipa 文件，很可能会有这种感受：“哇，这代码也太干净了吧。”
类名像 UserManager，方法名是 getUserToken，甚至资源图片都还叫 btn_login.png。一目了然，直接理解业务逻辑。

当然，安全问题远不止这些，但代码易读性本身就是安全隐患。

'''# 日常开发中，iOS 性能调优我们怎么做？聊聊我用过的几款工具

最近在给一个 iOS 视频类 App 做性能优化，过程中踩了不少坑，也用了一些不错的工具，今天就以一个开发者视角随便聊聊我在调试过程中的一些经验。

一、性能问题到底从哪里开始查？

大多数性能问题其实都是用户先反馈“卡”、“慢”、“闪退”等感知，或者自己在测试设备上感受到不流畅。而到了我们开发者手上，第一步通常不是去改代码，而是定位问题源头。

我的习惯是先观察资源占用，CPU、内存、GPU 都要看。官方工具 Instruments 是首选，功能强大，但也有学习成本高、启动慢的问题。在这方面，我现在更常用的是一个轻量级的监控工具 KeyMob，可以实时显示系统资源占用情况，还支持卡顿帧率监测、网络请求记录等，对我来说特别方便快速地排查方向。

二、调试日志与崩溃分析靠什么？

写 iOS 的都知道，Xcode 控制台输出的日志信息一旦真机多，杂讯就特别多。尤其是一些系统级别的日志经常被覆盖。

我用过一个组合是：Xcode 自带日志 + Bugly 崩溃收集 + KeyMob 实时日志辅助。KeyMob 有一个让我觉得比较贴心的地方，它能抓住 app 的 crash 日志，而且和用户实际操作时间贴合，还能抓住瞬时崩溃前几秒的操作链，这在做重现定位时非常有帮助。

三、文件操作与数据导出效率怎么提升？

开发过程中有时候我们需要查看应用沙盒内的文件，尤其是在处理一些导出调试数据、查看缓存文件的情况。我以前是用 iTools，但后来苹果对系统权限限制越来越多，导致很多工具失效。

KeyMob 的文件浏览和导出功能可以不越狱就查看 App 内部数据，这点我一开始没注意，但在查某个缓存泄漏问题时，确实靠这个省了不少工夫。另外也试过 iMazing，功能更全但偏重，对我这种调试为主的场景稍显复杂。

四、优化点滴靠积累，工具只是手段

其实调优这件事，说到底是靠细节积累的。比如我现在做的一件小事，是每次提交 PR 前会手动在测试机上跑一下性能监控，哪怕不是性能相关的功能，也至少确认一下是否出现新的内存峰值或线程异常增长。

我现在在用的组合大概是：

• Instruments（系统级别）
• KeyMob（日常监控与导出）
• Bugly（线上崩溃）
• Xcode 控制台 + Console 工具（日志）
• Occasionally iMazing（高级文件管理）

不是说哪个工具最好，而是哪个在不同阶段、不同问题上用着最顺手。

最后

现在很多开发工具都在“打广告”，但真正做开发的我们其实不太在乎界面多炫酷，更在意稳定和实用。希望这篇小记对你有启发，也欢迎你留言推荐你在用的性能工具，说不定我下次调 bug 就靠它了。'''

'''### 多端调试的那些坑，你踩过几个？

做移动端网页开发久了，最怕听到一句话：“iPhone 上这块显示有问题。”
你翻出模拟器、查 CSS、开控制台，花上半小时，最后发现——Android 正常，只有 iOS 的 WebView 出现样式错乱。更尴尬的是，问题只在某个具体版本的 Safari 中重现，模拟器甚至都复现不了。

这类 bug，调试难度常常不在逻辑，而在环境。

我们都试过这些“曲线救国”的办法：

• 用远程桌面连接物理设备，在控制台里尝试 console.log
• 把日志打印到后端，再看接口调用顺序
• 甚至用录屏、截图，把现象“传”给自己看

但效率真的很低，尤其当项目迭代频繁、上线时间紧张时，这种方法只会拖慢节奏。

几个值得一试的工具和方法（亲测有用）

我自己在项目中用过几种调试方式，分享几种组合，给有需要的朋友参考：

1. Chrome DevTools + Remote Debugging
   Android WebView 和 Chrome 浏览器调试效果不错，但不支持 iOS。
2. Safari Web Inspector
   支持 macOS + iOS 调试，但只能用 mac，还必须用特定版本的 Safari 搭配设备系统版本。
3. WebDebugX
   最近开始试用的一款工具，支持跨平台（Windows、Linux、macOS）调试 iOS 和 Android 的 WebView 或网页内容。
   调试流程接近 DevTools 的使用习惯，网络监控、DOM 观察、性能指标都比较完整。
   实际场景：之前有个小程序里的 H5 页面在低端 Android 上加载巨慢，网络分析面板一开，就发现原来是图片资源没压缩。优化后加载时间缩短了一半。
4. Charles/Fiddler 抓包
   网络层面抓包还是挺重要的，尤其是排查 HTTPS 请求失败或 token 错误的情况。

一点体会：调试手段决定了交付速度

我们常说“开发只是一半，调试才是上线的关键一步”。
尤其在多人协作或混合开发环境中，前端页面表现出现问题时，能够快速定位、复现并修复，是保障版本质量的核心能力。

如果你还在用模拟器 + 截图调 bug，不妨试试更新一些的调试方法，也许会带来意想不到的效率提升。

以上经验分享仅供参考，如果你有其他更顺手的跨平台调试组合，也欢迎评论区一起探讨。'''

subNvue的创建

subNvue作为vue或nvue页面的原生子窗体，当其父页面创建时，subNvue也随之创建，且仅创建一次，其生命周期也只会触发一次（包括onShow）。

subNvue的生命周期

在宿主页面创建时，subNvue的生命周期会依次执行，如onLoad\onMounted\onShow\onReady；
当宿主页面销毁时，剩下的如onUnmounted\onUnload也会依次执行。

值得一提的是，由于subNvue并非页面，即使返回打开，其onShow也只会在初始化时执行一次，如果想要监听其出现和隐藏的事件，可以利用其webview的性质，通过plus.webview.getWebviewById获取到势力，而后添加监听事件，例如：

const webView = plus.webview.getWebviewById(id);  
webView.addEventListener('show', doSomething);  
webView.addEventListener('hide', doSomething);

subNvue的销毁

从官方文档和社区了解到，官方并未给出明确的销毁方法，而是只提供了隐藏方法，然而实践下来，依然可以利用其webview的性质调用close方法进行销毁，不过这种方式官方并不推荐。

经过实践，subNvue的创建与销毁，是与其宿主界面强绑定的，宿主界面创建，它也创建，宿主界面销毁，它也自动销毁（宿主是tabbar的除外），大部分情况下是无需手动销毁的。

然而，上面的规律只对二级界面有效，对于一些寄宿在tabbar页面内的subNvue，其销毁就不知为何无法执行了。

当你多次创建tabbar界面（如reLaunch应用后重进tabbar），那个页面包含的subNvue也会随之多次创建，并保留在内存里。

通过调用 plus.webview.all 方法，在返回的webview列表里，你可以看到多个 id 相同但是 __uniapp_origin_id（父页面的id）不同的subNvue，这也就导致了几个问题：

• 当你想要通过getSubNVueById方法获取子窗体实例时，你获取到的可能并不是最新的实例，一旦你的子窗体有动态元素，最终渲染出的窗口也大概率是旧内容。
• 当你想要隐藏某个窗口时，情况也差不多，你无法精准拿到目前在界面上显示的子窗口实例，hide方法虽然执行了，但具体是哪个实例在执行，你也不知道。
• 所有旧的subNvue都会保存在内存里，即使父页面销毁也依然存留，无疑会增加性能消耗。

所幸，webview提供了close方法，我们可以筛选出id重复的subNvue，通过__uniapp_origin_id进行排序（新创建的页面，其id是递增的），之后手动清理即可。

const clearOldSubNvue = (id) => {  
  const webview = plus.webview  
    .all()  
    .filter((view) => view.id === id)  
    .sort((a, b) => +a.__uniapp_origin_id - +b.__uniapp_origin_id);  

  if (webview.length <= 1) return;  

  webview.forEach((view, index) => {  
    if (index < webview.length - 1) {  
      view.close();  
    }  
  });  
};

关于销毁的时机，可以利用其重复创建的性质，放在subNvue的onLoad或onReady里执行。

值得注意的是，如果我们在父页面销毁前统一销毁子窗口，之后再打开任意subNvue，都会导致navigateBack连续触发两次的bug，原因不明。

退回HBuilderX老版本 别更新，我怀疑手机 怀疑数据线 怀疑adb 就是没怀疑版本 我草！！！！！！！！！！！！！

'''开发者的 iOS 上架折腾记：没有 Mac，也能搞定？

最近在帮朋友把一个跨平台 Flutter 项目上架到 App Store，结果被 iOS 上架的那套流程卡得头都大了。其实这也不是第一次碰壁了——每次到“申请证书 + 打包 + 上传”的时候，开发节奏就被迫暂停，一堆额外配置压得人喘不过气。

问题其实很简单：不是每个人都有一台配置完整的 Mac 设备。很多时候我们写代码都在 Windows 或 Linux 环境里，平时跑模拟器、做调试都没事，但一旦到打包上传 App Store，那就是另一套生态。

这次我试着换了几个思路和工具组合，记录下来或许能帮到跟我一样不想买 Mac 的开发者。

方案一：租云 Mac + Xcode 手动操作（踩坑）

这是很多文章推荐的做法。用阿里云或者别的服务租个 Mac 云主机，上去装个 Xcode，远程登录后再操作证书申请、打包、上传。

实际体验下来——能用，但体验真的一般。

• 网络延迟让 Xcode 操作特别慢，连拖拽都卡
• 每次都要重新装环境，搞定权限
• 打包过程非常依赖图形界面，命令行体验不完整

如果你是纯命令行党，可能会抓狂。

方案二：CI/CD 工具链 + Fastlane 自动化（适合大团队）

有一次在公司项目里，我们用的是 GitLab CI + Fastlane 脚本来做自动上传。效果很好，自动申请证书、签名、打包上传一气呵成。但这个方案有几个前提条件：

• 有稳定的 Mac 运行节点（也可以是 macOS 服务器）
• 需要写大量配置文件，对 Fastlane 要熟悉
• 出错时 Debug 成本不低

这个方案更适合团队，但如果你是独立开发者或者外包项目，这种方式显得成本太高。

方案三：使用 Appuploader 简化流程（适合个人开发者）

后来我无意间发现了一个叫 Appuploader 的工具，试了一下感觉非常适合我这种非专业 iOS 开发者。

• 支持 Windows、Linux 甚至 Web 版使用
• 可以在线申请证书，自动处理开发者/发布证书和描述文件
• 上传 IPA 文件到 App Store 不依赖 Mac
• 图形界面操作，清晰直观，文档也详细

最关键的是——我完全没有碰 Xcode，也没有用 Mac，照样把 IPA 上传到了 App Store。

除了 Appuploader，还有其他实用工具推荐

如果你也在用 Flutter 或 React Native 开发跨平台 APP，可以考虑配合以下工具组合来提升效率：

• Visual Studio Code + Flutter 插件：轻量快速，适合跨平台开发调试
• Codemagic：CI/CD 平台，Flutter 项目上传 App Store 体验不错，不过免费额度有限
• Appetize.io：在线模拟器，适合展示 iOS 应用给客户预览

工具只是手段，最终目的还是少走弯路，把时间用在产品上而不是流程里。

写在最后

有时候觉得，开发者在技术栈之外，最大的挑战就是和各种平台规则打交道。App Store 上架本身不是很难，但流程复杂、设备要求高，加上每年系统更新带来的证书和描述文件规则变化，真的太容易让人崩溃。

希望这篇记录能给你一些启发。你有没有什么 iOS 上架的奇葩经历？欢迎一起交流～'''

'''最近在做一个多端 SDK 网络请求兼容性的测试，期间遇到一些 HTTPS 请求抓不到、iOS 抓包失效等问题，趁机整理一下我平时抓包时用到的几个工具和技巧，也顺便记录一下对比体验。

一、传统工具的局限

最早用的是 Charles 和 Fiddler，用它们配置代理，设置证书来抓 HTTPS 请求。PC 上用得还算顺手，但到了 iOS 就经常翻车——有些 App 根本不走系统代理，有些即使配置好证书，也因为 SSL Pinning 抓不到包。

Wireshark 是抓底层网络包的利器，但应用层的内容就没那么友好了。很多时候我只是想看一下 POST 请求发了什么数据，不需要那么重的工具。

二、几种工具组合对比

为了解决 iOS 抓包问题，我尝试了几种组合方案：

• mitmproxy + 自定义证书：功能强大，适合脚本化场景，但配置门槛高，需要一定 Python 基础；
• Proxyman：macOS 上用起来不错，界面也很清爽，但某些 App 抓不到包，还是逃不过 SSL Pin；
• Sniffmaster：这是最近开始尝试用的。支持插线抓包 iOS，无需配置代理或安装证书，甚至可以解密 HTTPS 和绕过双向 SSL Pin。最关键的是，它完全不需要注册登录，下载即用。

三、实际使用中的几个场景

1. 分析登录接口
   在调试某社交 App 登录流程时，iOS 请求失败，返回403。Charles 无法抓包，看不到完整内容。我用 Sniffmaster 插上设备，秒出数据包，定位出是 header 缺了个参数。用脚本改了请求，重试就成功了。
2. 分析微信小程序 HTTPS 请求
   小程序默认走自己的网络栈，很多代理工具抓不到，我用 Wireshark 抓 TCP 没法还原完整请求。但 Sniffmaster 插线直连，直接还原出 HTTPS 内容，非常方便。
3. 接口 Mock 与响应干预
   在 Sniffmaster 里可以写 JS 脚本，对请求或响应进行实时修改。例如调试支付流程时，我修改响应状态模拟成功支付，跳过了真实支付流程，方便进行后续页面调试。

四、总结

• Charles/Fiddler：老牌稳定，但面对 SSL Pin 或复杂抓包场景无力；
• Wireshark：适合协议分析，不适合日常应用层调试；
• Sniffmaster：对开发者特别友好，尤其是做 App、爬虫、接口调试这类工作的人，几乎是即插即用，功能覆盖非常全面。

如果你平时需要频繁调试网络请求，特别是对 iOS、HTTPS、双向认证这类需求比较多的，不妨试试第三个，我自己用了大概一周，效率提升真的非常明显。'''