Weather

起源 天气小程序产生于2022年年初，目的是用于验证自己是否有进入全栈开发（仅前后端）的能力。 受新冠疫情影响，2022年的春节是在杭州过的。还记得当时附近好几个地方都被划为了高风险，对整个区进行了管控。如果选择回家的话，得到将是14天的隔离，还不确定能否回来上班。因此便没有回去了。好在所在的区域情况并没有那么的严重，还是可以去买菜的。领了消费券，再加上公司发的年货，也没有想象中的那么糟糕。 所以，既然没有回去，又有十来天的时间，总得做点什么东西才行，对吧 🙄！ 2022年，是我工作的第四个年头。受多方面的信息影响，我也想看看验证自己是否有进入全栈开发（仅前后端）的能力。 历程 拂衣天气，又名微天气。 一个集地理信息与天气预报为一体的天气预报类小程序，界面精美，使用便捷。【致敬：和风天气】！ 💡 主要是有人给我说拂衣天气，听着还以为是卖衣服的。so，我就想着换个名字，就有了微天气。但是由于微信认证的原因，所以有些地方还是拂衣天气。现在细细想来，好像也没有什么关系，那就先这样吧 🙄 该项目从2022年1月12号正式启动，于2022年3月19日发布一阶段最终版本（1.1.9），总体耗时2个月零7天。从内容完整度以及界面友好程度来说，我给自己70分。 此前实在是没有经验，也没有相关的习惯，天气小程序开发过程中并没有编写相关的文档。所以在小程序开发完成之后，本来计划是将拂衣天气完整的开发过程通过文章的方式记录下来，并将该项目开源出去，甚至还想将该项目提交给和风天气。但最后的结果就是：文章就完成了四篇，也就是一个开头，没啥实际内容。@time 2022年8月16日 好的，现在时间来到2023年12月，我又有点时间了，因为我离职了（不是被裁）。这次的目标是完善文档，修复发现的一些BUG，然后新增一些内容，最终将该小程序开源，并贡献给和风天气。 接下来，让我来回忆一下每个阶段的详细内容 🤔 项目初始 为什么会想到做一个天气小程序呢？ 嗯，首先我是一个做服务端开发的GIS开发工程师。在当时刚结束一个小程序的开发工作，觉得小程序这个东西还挺有意思。同时受到周边各种信息的影响，也想试一试写点前端的内容，最好是可以方便发布的那种，也算是自己的作品不是。为什么会选择天气类别，好像是当时刷网页还是什么，看到一个人分享自己做了一个天气机器人，然后给女朋友推天气信息。so， 🫣 所以，我当时就想做一个天气类别的小程序，以此进行全栈开发能力的试炼。我想这会是一个微信小程序、是一个可以正常使用的小程序，以Java进行服务端开发，以Mapbox实现天气数据可视化。 本阶段事务分为了三个阶段，分别是：调研、学习、实现 调研 天气小程序什么最重要？当然是天气数据最为重要，所以首要内容便是确定天气数据的来源。其次便是确定本次天气小程序的技术实现构成。 天气数据 天气数据需要是真实的、可用的。那么可以通过网络中提供的天气API进行获取。 通过一定的检索后，我选定了两个天气平台，分别是：和风天气、心知天气。 高德天气：大平台，但是目前服务类目比较少 彩云天气：免费接口几乎没有，收费又太贵 心知天气 心知天气试用版与开发者版开发产品几乎等同，且开发者版收费也不贵。最为关键的是，支持以经纬度方式进行天气查询。 和风天气 几乎可以免费使用其提供的所有 API，且同样支持经纬度方式进行天气查询。 对比了这两者，发现至少都需要注册为开发者之后，才可以较好的使用其服务。且两者的开发者认证均需要实名。 关于天气API的选择，我最终选择了和风天气，倒不是因为它可以免费使用。其实，刚开始的时候我更倾向于使用心知天气，因为它还可以直接查昨天的天气（和风对于历史天气的查询比较麻烦）。但是和风天气首页结合了地图进行可视化，而且还提供有APP可以使用（方便参考）。再加上，我想了想，其实我并没有迫切的需要知道昨天的天气情况。 🙄 💡 其实最重要的原因在于：我先注册了心知天气（需要审核），过了半天后再去注册了和风天气（需要审核），但是最先通过审核的是和风天气（耗时大概也就半天左右，我是在春节期间注册的啊）。 技术实现构成 这里存在一个遗憾，小程序原生并不支持使用如mapbox这样的第三方地图框架，初始想法是通过webview的方式使用mapbox，但是遗憾的是，webview并不对个人类型的小程序开放使用。 所以，退而求其次，选择腾讯地图（及其提供的样式）实现地图浏览。 服务端程序则使用Java语言开发，天气数据是经过服务端代理的方式形成内部的数据接口，并非是小程序直接调用和风的接口 最终将服务端程序部署到阿里云 学习 我是一个后端开发工程师，我不怎么会写页面，我特别的讨厌写CSS。我也没有接触过前端开发和微信小程序开发，所以需要提前储备一下相关知识。 前端知识 我并没有想要精通前端技术，但是我需要比较体系的了解一下前端技术，方便进行小程序开发。所以我在B站找了两门前端视频学习（粗略的刷了一遍） 尚硅谷Web前端零基础入门HTML5+CSS3基础教程丨初学者从入门到精通 千锋web前端开发项目教程_1000集完全零基础入门HTML5+CSS3+JS到精通 微信小程序知识 其实就看官方文档就足够了，不过心虚的我还是在极客时间找了门课。最终发现：就官方文档就足够了，因为我并不需要很深入的东西 实现 在有一定准备后，就开始进入实现环节了。 在这里有一个大问题就是UI设计问题，我看和风天气APP就挺好看的，有天气有地图，身为GIS开发的我就很喜欢。又发现无论是和风天气官方，还是其他天气小程序应用，基本都没有携带地图的。 所以，我当即决定参考和风天气官方APP界面，做一个类似的天气小程序。当然，我做的这个小程序就是奔着开源，同时将作为作品分享给和风天气，才想着如此操作的。请务必慎重 🤔 在经过简单的设计过后，于2022年1月18日正式进行开发，2022年3月19日发布一阶段最终版本1.1.9。 文档补充 今天偷的懒，明天都会让你加倍还回来。此前一是没意识，二是认为没必要，三还是太懒，所以并没有同步编写文档。 现在计划将拂衣天气开发的完整过程通过文章的方式记录下来，下面是我对该整体内容的编写计划： 但是，我又要开始说但是了。打工人还是打工人！ 天气小程序于2022年4月前就已经完成了开发，直至到今天（2022年8月16日）也就才完成了三篇文章，不得不说拖延症是真的严重。天气小程序只是一个应用，就目前的投入收益来说，不应该把过多的时间放在小程序上面。在加上距离开发已经过去了4个月，开发之时并没有进行文档产出，所以现在才进行复盘则是相当于重新实现了一遍。就目前来看，核心的行政区划数据合并已基本完成，所以，后面将暂停小程序相关内容，变更为GIS基础与计算机基础的学习。 💡 对的，停更说明。 死灰复燃 打工是不可能打工的，只要我不打工，我就有时间了 🙄...

前言 服务端部署：由于并没有建立全链路的自动化部署，目前还需要到云服务器上进行环境制作（数据库，Nginx），并拉取后端服务进行部署 小程序发布：需要先完成服务端部署，保证应用正常可用 服务端部署 数据库安装与数据初始化 最开始的时候，我是直接将在操作系统上面安装数据库，后面发现迁移的时候还是不方便，即使我可以放弃数据库中的数据，但是还是需要重新创建数据表结构。 所以，在这一次中，我编写了一个Dockerfile脚本，使用一个空数据库作为模板，构建了postgis镜像。基于此，我可以实现快速的迁移与部署。由于这是一个实验性质的小程序，所以数据资产并不是十分重要（并不是说不安全，而是我可以丢弃），所以我可以安心的使用docker技术。在初始化postgis容器的时候，会同步释放模板以创建数据库。这将会带来一个问题是：如果重新创建容器，那么将会得到一个全新的数据库。当然你可以把数据库的data目录映射到宿主机上，应该可以解决这个问题。 docker build -t registry.cn-hangzhou.aliyuncs.com/fuyi-atlas/micro-weather-postgis:12-3.4 . 最后，我在本地完成该镜像的制作后，将其推送到我的阿里云镜像仓库中，便于后续使用。你可以注册一个阿里云账户去免费启用个人版的镜像仓库，也可以直接使用dockerhub。 docker push registry.cn-hangzhou.aliyuncs.com/fuyi-atlas/micro-weather-postgis:latest 应用部署 于本地完成镜像制作，并推送到阿里云镜像仓库中。 为了更方便的进行部署，我编写了docker compose脚本，用于将数据库与应用服务端程序一并启动。目前程序中有一个海报分享的功能，该功能实现中需要一些额外的中文字体的支持，所以需要将此部分中文字体放置到宿主机的某个目录下，并在环境变量中指定该目录，脚本中会将该目录映射该到容器内的/usr/share/fonts目录下 对于图片访问，还是延续此前的实现，即在服务器端生成分享海报，存储到本地（指服务器磁盘），而后通过Nginx代理访问。由于目前的服务器我是与他人共用，同时还需要配置域名证书，所以暂时没有将Nginx的部署同步放置到docker compose脚本中。 💡 由于部署中需要提供部分敏感信息，比如：小程序的密钥、天气应用的key、docker镜像仓库地址。我将所有信息以环境变量的方式进行占位，通过docker compose的环境变量进行替换，即.env文件 小程序发布 小程序端的发布就比较简单了 先将base_url更换为正式环境的地址（我没有提交此部分代码，你可以自己更改） 本次调试没有问题后，就可以上传代码，即提交为体验版本 而后使用体验版本测试没有问题，就可以提交审核 审核通过后，就可以发布了 总体来看，本次发布很顺利，审核在十分钟就通过了。

前言 这里暂不作过多的操作，还是保持与此前一致。即通过Github Action完成Docker Image的build与push，目标仓库为阿里云容器镜像服务实例（个人版）registry.cn-hangzhou.aliyuncs.com 那么一共分为三个部分： Dockerfile编写 阿里云容器镜像服务配置 Github Action Dockerfile编写 jdk17 gradle FROM gradle:jdk17-alpine AS build # 设置语言，支持中文 ENV LANG C.UTF-8 COPY --chown=gradle:gradle . /opt/gradle/src WORKDIR /opt/gradle/src RUN gradle clean build -x test --no-daemon FROM eclipse-temurin:17-jdk-jammy COPY --from=build /opt/gradle/src/build/libs/*.jar /usr/app/ WORKDIR /usr/app/ RUN sh -c 'touch micro-weather-backend-1.0.0-RELEASE.jar' ENTRYPOINT ["java", "-jar", "micro-weather-backend-1.0.0-RELEASE.jar"] Github Action 先在阿里云镜像服务中创建命名空间 创建仓库（可选，因为可以自动创建） 编写Github Action脚本 name: Micro Weather Service Image Build And Push CI on: push: branches: - 'main' jobs: docker: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v2 # setup-qemu 如果您想使用 QEMU 添加仿真支持以便能够针对更多平台进行构建，则 action 会很有用 - name: Set up QEMU uses: docker/setup-qemu-action@v1 # setup-buildx-action 将默认使用docker-container 构建器驱动程序创建和引导构建器。非必需 - name: Set up Docker Buildx uses: docker/setup-buildx-action@v1 - name: Login to Aliyun DockerHub uses: docker/login-action@v1 with: registry: ${{secrets....

前言 此前提到微天气应用程序需要使用到行政区划数据，不过上一章所使用的数据来源于网络，或多或少都可以考虑一下是否还有其他获取的方式，所以也就有了本文的内容。 在这里，将基于全国1:100万基础地理信息数据进行行政区划数据的提取。本文用于记录使用程序实现全国1:100万基础地理信息数据合并的全过程。 当然，本文产生的最重要原因其实并不是受到微天气的启发，更多的是个人想试一试能不能用。 数据说明 全国1：100万公众版基础地理信息数据（2021）覆盖全国陆地范围和包括台湾岛、海南岛、钓鱼岛、南海诸岛在内的主要岛屿及其临近海域，共77幅1:100万图幅，该数据集整体现势性为2019年。数据采用2000国家大地坐标系，1985国家高程基准，经纬度坐标。 为满足广大社会群众对地理信息数据资源的需求，经自然资源部授权，全国地理信息资源目录服务系统提供全国1:100万全图层要素免费下载的服务。下载数据采用1：100万标准图幅分发，内容包括水系、居民地及设施、交通、管线、境界与政区、地貌与土质、植被、地名及注记9个数据集，且保存要素间空间关系和相关属性信息。 💡 提供下载的是矢量数据，不是最终地图，与符号化后的地图再可视化表达上存在一定差异。用户利用此数据编制地图，应当严格执行《地图管理条例》有关规定；编制的地图如需向社会公开的，还应当依法履行地图审核程序。 成果规格 分幅编号及范围 1：100万公众版基础地理信息数据（2021）的图幅总数为77幅，分幅数据按照GB/T 13989-2012《国家基本比例尺地形图分幅和编号》执行。空间存储单元为6°（经差）×4°（纬差）。 坐标系统 平面坐标系： 2000国家大地坐标系。 高程基准：1985国家高程基准。 地图投影：分幅数据采用地理坐标，坐标单位为度。 几何精度 更新后地物点对于附近野外控制点的平面位置和高程中误差符合下表的要求，以两倍中误差值为最大误差。 地物点误差 最小 最大 平面位置 100 500 高程 50 200 现势性 1:100万地形数据现势性与更新使用的数据源的现势性一致，数据整体现势性达到2019年。 成果数据组织 全国1：100万公众版地形数据（2021）内容包括水系、居民地及设施、交通、管线、境界与政区、地貌与土质、植被、地名及注记9个数据集。 数据分层的命名采用四个字符，第一个字符代表数据分类，第二三个字符是数据内容的缩写，第四个字符代表几何类型。 目标 实现分图层合并（处理图幅合并时接边问题） 水系（暂缓） 交通（暂缓） 境界与政区（国、省、市、县） 地名及注记 根据合并后的行政区划与地名注记，制作行政区划数据库 数据库使用PostgreSQL（PostGIS） 设计 图层解析程序 Java程序， 使用GDAL 读取GDB 逻辑 根据《国家基本比例尺地形图分幅和编号》规定可知网格范围，通过网格范围动态生成对应网格的分幅编号，并以该编号进行数据检索。如果命中则根据成果数据组织规格以及相关标准对数据进行解析，如果未命中则跳过，直至网格扫描完毕。 经度：72~138（E），43~53（11） 纬度：0~56（N），A~N（14） 即，网格范围:[43,53] x [A,N] 数据的处理流程可使用责任链模式进行，后续也方便加入其他的处理流程。即，整体的执行框架为策略模式+责任链模式。为统一策略选择模型，在此提出图层定义（LayerDefinition）的概念。 LayerDefinition由如下几个关键要素组成： 图层数据源（LayerSource） driver：驱动，参考java.sql.UnWrapper实现 instance name catalog： schema： table： commonDefinitionKey ：常规定义缓存的key fieldDefinitionKey ：字段定义缓存的key featureCarrierKey ：要素载体缓存的key origin：数据来源（分幅文件路径） scale：比例尺（如：1000000，表示1:1000000） sourceSpatialRef：源坐标系（表现形式可为标准ID、PROJ Text、WKT Text） sinkSpatialRef：目标坐标系（表现形式可为标准ID、PROJ Text、WKT Text） featureCode：要素分类码，对应成果数据组织中的要素分类（如：C、B） name：图层命名，也是图层分类码 layerCode：图层分类码 release：释放格式（比如：WMTS、Shapefile、GDB…） 描述字符为：比例尺:源坐标系:目标坐标系:要素分类码:图层名称:释放格式，在描述字符串中，坐标系仅使用标准ID表示...

前言 微天气程序中存在如下几个功能需要使用到行政区划数据： 城市列表，需要支持城市搜索 根据经纬度获区域（城市）的天气数据 地图坐标拾取并获取所处区域（城市）信息，同时获取天气数据 对于城市的天气数据，不使用和风天气的城市列表，而是自行维护，通过空间位置（经纬度）进行关联。对于城市位置的定义，本可以选择如行政中心或市中心，但我没有这样的数据，就直接用城市区划范围的中心点代替。不准确不重要，过程已经满足了，且后续是可以替换的。 其实完全可以使用官方提供的城市数据和GeoAPI覆盖这些功能，但既然我是做GIS开发的，而且手里也有可以用作研究学习的数据，为啥不用呢。 今天突然发现，其实我可以爬一下和风的数据，这样就可以拿到城市选择的经纬度数据了 @time 2023.10.10 About 行政区划解析程序，输入shape文件，写入Postgresql. 大体完整的四级行政区划数据组织 github link: fuyi-district-parse 数据情况 数据原源于网络，由于时间久远，我已经忘记了是如何获取到的 名词解释 省级行政区 中国的一级行政区，或称国家一级行政区或省级行政区，是指直属中央政府管辖的行政区划，在历史上曾有不同的称呼。如：省、自治区、直辖市、特别行政区。 地级行政区 地级行政区即“地区级别行政区”，是现行中华人民共和国行政区划中常规的第二级行政区划单位，包括地级市、地区、盟、自治州等。地级行政区隶属于省、自治区、直辖市等省级行政区之下；下辖若干个县、区、县级市、旗等县级行政区。作为特例，东莞市、中山市、嘉峪关市、儋州市等四个地级市下辖街道办事处与乡镇，不辖县、区，因此也称作“直筒子（地级）市”。地级行政区的级别为正厅级，所以非正厅级的省直辖的行政区划不算作地级行政区，例如：湖北省辖的仙桃市、天门市、潜江市；河南省辖的济源市等等。直辖市下辖的区，虽然是正厅级，但未列入地级行政区的统计。 县级行政区 县为中华人民共和国行政区划单位之一，县级行政区指行政地位与“县”相同的行政区划单位的总称，其管辖乡级行政区。为乡、镇的上一级行政区划单位。中华人民共和国成立后，随着行政督察区名称的变更，除各直辖市均隶属于专区（行政督察专区）、地区或地级行政区，现除各直辖市、海南省直管县外均为地级行政区的下一级行政区。 按省、县、乡三级行政区划制度划分，县级行政区属于第二级行政区，为直辖市的下级行政区划单位。 按省、地、县、乡四级行政区划制度划分，县级行政区属于第三级行政区，属于省、自治区所辖地级行政区的下级行政区划单位。 乡级行政区 乡，中华人民共和国现行基层行政区划单位，区划层次介于县与村之间。“乡”为县、县级市下的主要行政区划类型之一。中国行政区划史上，“乡”一直为县的行政区划单元，因此现行处同一层次的区划单位归入乡级行政区。中国自改革开放以来，由于城市的快速扩张，行政区划制度出现了大的变革。1980年代以后“乡改镇”、“乡改街道”的现象越来越普遍。 在乡级行政区划中，乡（包括镇）设有一级人民政府，属于基层政权；乡的行政区划单位为村（含民族村）。但很多乡设有社区，乡的区划单位设置与镇、街道看不出实质性差异。 目的 解析所有数据文件，实现最终入库 使用GeoTools实现 数据库表结构： 行政区划信息（district_info） id：自增Id（bigserial） name：行政区划名称 grade：行政区划等级（省级行政区：1， 地级行政区：2， 县级行政区：3，） code：行政区代码 center_point：中心点（geometry::point） bounds：行政区边界（geometry） 注： 数据入库前审查，保证行政区代码唯一 使用grade区分省、市、县、乡镇 对于省、市、县code列，统一进行前6位截取（不满6位字符所在数据，直接丢弃），对于乡镇则统一进行前9位进行截取（不满9位字符所在数据，直接丢弃） 省级行政区 存在错乱数据，可以使用行政区代码识别（adcode） 地级行政区 存在错乱数据，可以使用行政区代码识别（code），需要截取前6位 县级行政区 存在错乱数据，可以使用行政区代码识别（code），需要截取前6位 乡级行政区 成果 记录数：46652 点数据为各个行政区中心点 数据表 PostGIS CREATE EXTENSION IF NOT EXISTS postgis WITH SCHEMA public; 行政区划 -- -- Name: district_info_id_seq; Type: SEQUENCE; Schema: public; Owner: postgres -- CREATE SEQUENCE public....

前言 本文用于说明本次开发所使用的环境，以及环境的搭建过程。 操作系统 Windows 10 专业版 其实我当时使用的操作系统的Arch Linux，开发完成后才又重装回Windows。 现在又用回了Fedora 38 Workstation @time 2023.10.07 服务端 服务端使用Java语言进行开发，项目构建使用Maven(Gradle)，开发工具使用Idea，服务发布使用Docker，下面是具体的版本： JDK: OpenJDK 11 Gradle: 7.3.2 Maven: Idea: IntelliJ IDEA 2022.1.3 (Community Edition) Docker: Linx Docker Desktop Version 4.23.0 (120376) [Engine: 24.0.6] 小程序 首先需要自行完成小程序的注册，具体可以参考官方文档。 其次，下载并安装小程序开发工具，参见下载页面。 最后，调试基础库选择：2.24.6 参考 开发者工具中无法显示echart或显示异常 在MobaXterm进入ssh终端后，键入上下左右出现乱码 win10上修改docker的镜像文件存储位置 WSL2 迁移 Docker 镜像存储位置 说明 如有冒犯，我在这里先向您道歉，还请联系我进行处理 email: thread_zhou@126.com

前言 这是一个前后端分离的项目，后端使用Java进行开发，而前端通过微信小程序实现。 功能结构 可从上图得知，部分功能已去除： 消息 消息推送 紧急情况推送 用户 个人中心 模型设计 用户信息（UserInfo） id Long 主键 oid String OpenID uid String UnionID name String 昵称 phone_num String 手机号 avatar String 头像地址 authState String 登录状态 Silence 静默登录（目前程序的访问是需要存在登录态的） Authorized 已授权 createTime Timestamp 记录创建时间 updateTime Timestamp 记录更新时间 行政区划信息（DistrictInfo） 使用全国行政区划信息填充，含空间数据，数据粒度到区县。目前仅支持国内数据。 id Long 主键 name String 行政区名称 grade Integer 行政区级别 1：省级行政区 2：地级行政区 3：县级行政区 4：乡镇级行政区 code String 行政区代码 centerPoint Point 行政区中心点（空间数据） bounds Geometry 行政区边界（空间数据） 关注城市（FollowCity） id Long 主键 userId Long 用户ID districtId Long 行政区划ID districtName String 行政区划名称 districtCode String 行政区划编码 orderNum Integer 序号，自然数，从1开始 createTime Timestamp 记录创建时间 天气信息 由于天气数据均来自第三方，目前数据格式于和风天气对齐。...

前言 俗话说：磨刀不误砍柴工。 我想做一个天气类别的小程序，以此进行全栈开发能力的试炼。我想这会是一个微信小程序、是一个可以正常使用的小程序，以Java进行服务端开发，以Mapbox实现天气数据可视化。 但是我是一个后端开发工程师，我不怎么会写页面，我特别的讨厌写CSS。我也没有接触过微信小程序开发，也仅仅知道过Mapbox可以实现好看的地图。所以我需要进行一定的预研，避免后期花费更大的精力用来调整本可以避免的问题。 下面是我计划实现的功能列表： 利用网络接口获取数据（昨日天气、当前天气、预报天气） 实现实时天气与预报数据查看 紧急情况推送 利用地图（mapbox）进行数据可视化 天气分享（图片分享，页面分享） 常用地址 消息推送 个人信息 登录授权 应用Promise进行异步网络请求 使用阿里巴巴矢量图标库作为图标数据源 echarts图标展示 接入疫情数据？ 预研对象 天气数据 天气数据需要是真实的、可用的。那么可以通过网络中提供的天气API进行获取。 通过一定的检索后，我选定了两个天气平台，分别是：和风天气、心知天气。 高德天气：大平台，但是目前服务类目比较少 彩云天气：免费接口几乎没有，收费又太贵 心知天气 心知天气试用版与开发者版开发产品几乎等同，且开发者版收费也不贵。最为关键的是，支持以经纬度方式进行天气查询。 和风天气 几乎可以免费使用其提供的所有 API，且同样支持经纬度方式进行天气查询。 小结 对比了这两者，发现至少都需要注册为开发者之后，才可以较好的使用其服务。且两者的开发者认证均需要实名。 关于天气API的选择，我最终选择了和风天气，倒不是因为它可以免费使用。其实，刚开始的时候我更倾向于使用心知天气，因为它还可以直接查昨天的天气（和风对于历史天气的查询比较麻烦）。但是和风天气首页结合了地图进行可视化，而且还提供有APP可以使用（方便参考）。再加上，我想了想，其实我并没有迫切的需要知道昨天的天气情况。 其实最重要的原因在于：我先注册了心知天气（需要审核），过了半天后再去注册了和风天气（需要审核），但是最先通过审核的是和风天气（耗时大概也就半天左右，我是在春节期间注册的）。 前端技术 我并没有想要精通前端技术，但是我需要比较体系的了解一下前端技术，方便进行小程序开发。所以我在B站找了两门前端视频学习（粗略的刷了一遍）： 【尚硅谷】Web前端零基础入门HTML5+CSS3基础教程丨初学者从入门到精通 千锋web前端开发项目教程_1000集完全零基础入门HTML5+CSS3+JS到精通 微信小程序 官方文档足以 Mapbox 这里存在一个遗憾，小程序原生并不支持使用如mapbox这样的第三方地图框架，初始想法是通过webview的方式使用mapbox，但是遗憾的是，webview并不对个人类型的小程序开放使用。 所以，退而求其次，选择腾讯地图（及其提供的样式）实现地图浏览。 UI UI部分参考和风天气APP，以及WEUI 总结 天气API使用和风天气（若有空余可考虑抽取一套统一的API，可组合或切换数据来源） 地图使用腾讯地图（微信小程序解决方案，主要在于个性化样式的使用） 基于自定义服务端实现天气代理以及小程序静默登录 UI参考和风天气APP实现 参考 最好的6个免费天气 API 接口对比测评 心知天气-价格方案 和风天气-FAQ H5+Javascript技术结构图 腾讯位置服务-微信小程序解决方案-个性化地图样式 说明 如有冒犯，我在这里先向您道歉，还请联系我进行处理 email: thread_zhou@126.com

前言 天气小程序产生于2022年年初，目的是用于验证自己是否有进入全栈开发（仅前后端）的能力。该项目从2022年1月12号正式启动，于2022年3月19日发布一阶段最终版本（1.1.9），总体耗时2个月零7天。从内容完整度以及界面友好程度来说，我给自己70分。 完成内容 和风天气API接入，可实现实时天气、实时空气、24小时天气预报、7天天气预报 使用echarts for wechat进行24小时天气预报展示 通过腾讯位置服务提供的微信小程序解决方案实现地图个性化展示（目前使用风格：白浅） 通过自建服务实现小程序静默登录 通过自建服务实现关注城市的持久化管理 实现天气分享功能，通过生成一张图片进行分享，可直接分享给朋友或群组 默认通过定位获取所在位置的天气数据 天气数据均通过服务端代理进行获取，从而避免相关key直接暴露在客户端 提供通过经纬度查询所处行政区划的服务，提供行政区划查询服务，皆可获取对应行政区划中心点基于边界数据，数据坐标为4326 服务通过github action自动化进行docker构建，并推送到阿里云镜像服务仓库，而后在阿里云ecs中直接拉取docker进行部署 图片服务则是通过nginx实现反向代理，图片由docker容器内服务创建，通过docker文件映射功能映射到云主机，再通过nginx可实现图片的访问 服务与图片均实现域名访问，且均提供ssl证书 不足 未实现天气地图可视化，即基于mapbox进行地图可视化（webview需要企业认证资质） 未提供坐标转换功能，因目前使用的是腾讯地图（gcj02，即从地图获取的数据均为gcj02），行政区划数据为4326（wgs84），目前是直接将4326作为gcj02进行使用（因为数据的粒度为区县，所以差异不会很大，除非在行政区边界处可能会出现行政区显示错误问题） 未完整实现小程序朋友圈分享功能，因该功能需要所分享页面的数据可直接获取，且分享页面小程序登录功能已被限制，所以目前无法直接提供数据获取服务（需要进行登录态校验，考虑到被攻击的可能） 未完成天气预警数据接入与提示功能 未完成数据推送、个人主页、图层管理功能 分享图片中未实现天气云图叠加功能，仅获取了所在位置范围的影像图与相关注记 服务端代码封装度不够，且DDD的认知不足，导致实践乱七八糟 内容 我计划将拂衣天气开发的完整过程通过文章的方式记录下来，下面是我对该整体内容的编写计划： Name Key Words Summary 序章 前期调研 模型设计 开发环境准备 行政区划数据准备 小程序静默登陆实现 小程序开发（一） 说明主页布局构建，组件拆分情况，实现地图加载以及定位 小程序开发（二） 实现上下滑动功能开发，以及左右滑动组件封装 小程序开发（三） 实时天气栏卡片、文字描述、底部7天天气预报以及Footer部分开发 小程序开发（四） 完成echarts组件封装 天气代理服务开发 提供实时天气、实时空气质量、24小时天气预报、7天天气预报代理服务开发 小程序开发（五） 完成天气部分API对接 行政区划服务开发 提供行政区划查询服务 关注城市服务开发 提供对城市的关注与取消关注能力 小程序开发（六） 完成天气图片分享功能 小程序开发（七） 完成城市选择页面开发与数据API对接 Github Action服务发布 小程序服务发布 终篇 参考 注：拂衣天气小程序的界面设计与交互设计主要参考和风天气APP。当前所述拂衣天气小程序的开发主要用于学习。 致敬和风天气！ 和风天气 和风天气开发平台