你的浏览器禁用了JavaScript, 请开启后刷新浏览器获得更好的体验!

: 环信即时通讯云
单聊、群聊、聊天室...

: 环信开发文档

: Demo体验
场景Demo，开箱即用

: RTE开发者社区
汇聚音视频领域技术干货，分享行业资讯

: 技术讨论区
技术交流、答疑

: 资源下载
收集了海量宝藏开发资源

: iOS Library
不需要辛辛苦苦的去找轮子, 这里都有

: Android Library
不需要辛辛苦苦的去找轮子, 这里都有

如何使用Electron集成环信UIKIT

环信_WebIM

写在前面环信单群聊 UIKit 是基于环信即时通讯云 IM SDK 开发的一款即时通讯 React UI 组件库，本篇文章介绍如何在Electron中如何集成UIKit，采用框架Electron-vite-react--- 准备工作1.已经在环信即时...

继续阅读 »

写在前面
环信单群聊 UIKit 是基于环信即时通讯云 IM SDK 开发的一款即时通讯 React UI 组件库，本篇文章介绍如何在Electron中如何集成UIKit，采用框架Electron-vite-react

---
准备工作
1.已经在环信即时通讯云控制台创建了有效的环信即时通讯 IM 开发者账号，并获取了App Key。

2.了解并可以创建Electron-vite-react项目

3.了解UIkit各功能以及api调用

---

开始集成
第一步：创建一个Electron项目进度10%
Electron-vite官网有详细的教程，此处不做过多赘述，仅以当前示例项目为参考集成，更多详情指路官网

yarn create @quick-start/electron electronReact --template react

第二步：安装依赖进度15%

yarn install

第三步：启动项目进度20%

yarn run dev

到这一步我们可以得到下图

你的目录结构如下图

第四步：安装UIKit进度50%

下载easemob-chat-uikit
使用 npm 安装 easemob-chat-uikit 包

npm install easemob-chat-uikit --save

使用 yarn 安装 easemob-chat-uikit 包

yarn add easemob-chat-uikit

第五步：引入UIKit组件进度80%

1、删除App.tsx自带的内容，在App.tsx中引入UIKit组件

import {
  Provider as UIKitProvider,
  Chat,
  ConversationList,
  useClient
} from 'easemob-chat-uikit'
import 'easemob-chat-uikit/style.css'
import { useEffect } from 'react'
import './App.css'
const ChatApp = () => {
  const client = useClient()
  useEffect(() => {
    client &&
      client
        .open({
          user: 'userId',
          pwd: 'pwd'
        })
        .then((res) => {
          console.log('get token success', res)
        })
  }, [client])
  return (
    <div className="app_container">
      <div className="conversation_container">
        <ConversationList />
      </div>
      <div className="chat_container">
        <Chat />
      </div>
    </div>
  )
}
function App(): JSX.Element {
  return (
    <UIKitProvider
      initConfig={{
        appKey: 'your app key'
      }}
    >
      <ChatApp />
    </UIKitProvider>
  )
}

export default App

2、将src/renderer/src/assets/main.css中的css样式全部替换如下

body {
  display: flex;
  flex-direction: column;
  font-family:
    Roboto,
    -apple-system,
    BlinkMacSystemFont,
    'Helvetica Neue',
    'Segoe UI',
    'Oxygen',
    'Ubuntu',
    'Cantarell',
    'Open Sans',
    sans-serif;
  color: #86a5b1;
  background-color: #2f3241;
}

* {
  padding: 0;
  margin: 0;
}

ul {
  list-style: none;
}

code {
  font-weight: 600;
  padding: 3px 5px;
  border-radius: 2px;
  background-color: #26282e;
  font-family:
    ui-monospace,
    SFMono-Regular,
    SF Mono,
    Menlo,
    Consolas,
    Liberation Mono,
    monospace;
  font-size: 85%;
}

a {
  color: #9feaf9;
  font-weight: 600;
  cursor: pointer;
  text-decoration: none;
  outline: none;
}

a:hover {
  border-bottom: 1px solid;
}

.container {
  flex: 1;
  display: flex;
  flex-direction: column;
  max-width: 840px;
  margin: 0 auto;
  padding: 15px 30px 0 30px;
}

.versions {
  margin: 0 auto;
  float: none;
  clear: both;
  overflow: hidden;
  font-family: 'Menlo', 'Lucida Console', monospace;
  color: #c2f5ff;
  line-height: 1;
  transition: all 0.3s;
}

.versions li {
  display: block;
  float: left;
  border-right: 1px solid rgba(194, 245, 255, 0.4);
  padding: 0 20px;
  font-size: 13px;
  opacity: 0.8;
}

.versions li:last-child {
  border: none;
}

.hero-logo {
  margin-top: -0.4rem;
  transition: all 0.3s;
}

@media (max-width: 840px) {
  .versions {
    display: none;
  }

  .hero-logo {
    margin-top: -1.5rem;
  }
}

.hero-text {
  font-weight: 400;
  color: #c2f5ff;
  text-align: center;
  margin-top: -0.5rem;
  margin-bottom: 10px;
}

@media (max-width: 660px) {
  .hero-logo {
    display: none;
  }

  .hero-text {
    margin-top: 20px;
  }
}

.hero-tagline {
  text-align: center;
  margin-bottom: 14px;
}

.links {
  display: flex;
  align-items: center;
  justify-content: center;
  margin-bottom: 24px;
  font-size: 18px;
  font-weight: 500;
}

.links a {
  font-weight: 500;
}

.links .link-item {
  padding: 0 4px;
}

.features {
  display: flex;
  flex-wrap: wrap;
  margin: -6px;
}

.features .feature-item {
  width: 33.33%;
  box-sizing: border-box;
  padding: 6px;
}

.features article {
  background-color: rgba(194, 245, 255, 0.1);
  border-radius: 8px;
  box-sizing: border-box;
  padding: 12px;
  height: 100%;
}

.features span {
  color: #d4e8ef;
  word-break: break-all;
}

.features .title {
  font-size: 17px;
  font-weight: 500;
  color: #c2f5ff;
  line-height: 22px;
  overflow: hidden;
  text-overflow: ellipsis;
  white-space: nowrap;
}

.features .detail {
  font-size: 14px;
  font-weight: 500;
  line-height: 22px;
  margin-top: 6px;
}

@media (max-width: 660px) {
  .features .feature-item {
    width: 50%;
  }
}

@media (max-width: 480px) {
  .links {
    flex-direction: column;
    line-height: 32px;
  }

  .links .link-dot {
    display: none;
  }

  .features .feature-item {
    width: 100%;
  }
}

3、在src/renderer/src目录下添加App.css

.app_container {
  width: calc(100%);
  height: 100vh;
  display: flex;
}
.conversation_container {
  width: 30%;
}
.chat_container {
  width: 70%;
}

到这一步你可以得到如下图

第六步：解决问题`进度99%`

在第五步执行完毕之后发现调试器有如下图报错

经查阅资料，发现是Electron内容安全策略在搞鬼，并提供了解决方案

接下来我们就需要在src/renderer/index.html中更改meta标签
同样out/renderer/index.html也需要更改meta标签

<meta
      http-equiv="Content-Security-Policy"
      content="font-src 'self' data:; img-src 'self' data:; default-src 'self'; connect-src * ws://* wss://*; script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline'"
    />

接下来保存代码并运行你将得到下图

第七步：发送消息进度100%
点击好友并发送一条消息，如下图

恭喜你集成完毕～
总结：
通过以上步骤，你已经成功在Electron中集成了环信单聊 UIKit 并实现了基本的即时通讯功能，接下来继续根据 UIKit 提供的组件和 API 文档进行进一步开发吧

收起阅读 »

Go 再次讨论 catch error 模型，官方回应现状

综合技术讨论

大家好，我是煎鱼。最近社区的同学和 Go 官方又因为错误处理的提案屡屡被否，发生了一些小的摩擦。也非常难得的看到核心团队成员首次表达了目前的态度和情况。基于此，我们今天进行该内容分享。紧跟 Go 官方最新进展。快速背景 Go 的错误处理机制，主要是依赖于...

继续阅读 »

大家好，我是煎鱼。

最近社区的同学和 Go 官方又因为错误处理的提案屡屡被否，发生了一些小的摩擦。也非常难得的看到核心团队成员首次表达了目前的态度和情况。

基于此，我们今天进行该内容分享。紧跟 Go 官方最新进展。

快速背景

Go 的错误处理机制，主要是依赖于 if err != nil 的方式。因此在对函数做一定的封装后。

代码会呈现出以下样子：



jy1, err := Foo1()

if err != nil {

    return err

}

jy2, err := Foo2()

if err != nil {

    return err

}

err := Foo3()

if err != nil {

    return err

}

...

有部分开发者会认为这比较的丑陋、混乱且难以阅读。因此 Go 错误处理的优化，也是社区里一直反复提及和提出的领域。饱受各类争议。

新提案：追求类似 try-catch

最近一位国内的同学 @xiaokentrl 提了个类似 try catch error 的新提案，试图用魔法打败魔法。

原作者给出的提案内容是：

1、新增环境变量做开关：

ERROR_SINGLE = TRUE   //error_single = true

2、使用特定标识符来做 try-catch：

Demo1 单行错误处理：

//Single-line error handling

file, err := os.Create("abc.txt") @ return nil , err

defer file.Close()

Demo2 多行错误处理：

func main() {

    //Multiline error handling

    :@



    file, err:= os.Open("abc.txt")

    defer file.Close()



    buf := make([]byte, 1024)

    _, err2 := file.Read(buf)



    @ err | err2  return ...

}

主要的变化内容是：利用标签 @ 添加一个类似 try-catch 的代码区块，并添加运算符和相关错误处理的联动规则。

这个提案本身，其实就是以往讲到的 goto error 和 check/with 这种类似 try-catch 的模式。

当然非常快的就遭到了 Go 核心团队的反对：

@Ian Lance Taylor 表示：由于很难处理声明和应用，如果一个标签的作用域中还有其他变量，就不能使用 goto。

新的争端：官方你行你上

社区中有同学看到这一次次被否的错误处理和关联提案们，深感无奈和无语。他发出了以下的质疑：

“为什么不让 Ian Lance Taylor 和/或 Go 核心团队的其他成员提出改进的错误处理框架的初始原型，然后让 Go 社区参与进来，为其最终形式做出贡献呢？Go 中的泛型正是这样发展到现在的。

如果我们等待 Go 社区提出最初的原型，我认为我们将永远不会有改进的 Go 错误处理框架，至少在未来几年内不会。”

但其实很可惜，因为人家真干过。

Go 核心团队是有主动提出过错误处理的优化提案的，提案名为《Proposal: A built-in Go error check function, try》，快速讲一下。

以前的代码：

f, err := os.Open(filename)

if err != nil {

	return …, err  // zero values for other results, if any

}

应用该提案后的新代码：

f := try(os.Open(filename))

try 只能在本身返回错误结果的函数中使用，且该结果必须是外层函数的最后一个结果参数。

不过很遗憾，该官方提案，喜提有史以来被否决最多的提案 TOP1：

最终该提案也由于形形色色的意见，最终凉了。感觉也给 Go 核心团队泼了一盆凉水，因为这是继 check/handle 后的 try，到目前也没有新的官方提案了。

Go 官方回应

本次提及的新提案下，大家的交流愈演愈烈，有种认为就是 Go 核心团队故意不让错误处理得到更好的改善。

此时 Go 核心团队的元老之一 @Ian Lance Taylor 站出来发声，诠释了目前 Go 团队对此的态度。这也是首次。

具体内容如下：

“我们愿意考虑一个有良好社区支持的好的错误处理提案。

不幸的是，我很遗憾地说，基本上所有新的错误处理提案都不好，也没有社区支持。例如，这个提案有 10 个反对票，没有赞成票。我当然会鼓励人们在广泛使用这门语言之前，避免提交错误处理提案。

我还鼓励人们审查早期的提案。它们在这里：github.com/golang/go/i… 。目前已有 183 个并在不断增加。

我自己阅读了每一个。重要的是，请记住，对已被否决提案的微调的新提案也几乎肯定也会被否决。

并且请记住，我们只会接受一个与现有语言契合良好的提案。例如：这个提案中使用了一个神奇的 @ 符号，这完全不像现有语言中的任何其他东西。

Go 团队可能会在适当的时候提出一个新的错误处理提案。然而，正如其他人所说，我们最好的想法被社区认为是不可接受的。而且有大量的 Go 程序员对现状表示满意。”

总结

目前 Go 错误处理的情况和困境是比较明确的，很多社区同学会基于以往已经被否决的旧提案上进行不断的微改，再不断提交。

现阶段都是被全面否定的，因为即使做了微调，也无法改变提案本身的核心思想。

而 Go 官方自己提出的 check/handle 和 try 提案，在社区中也被广大的网友否决了。还获得了史上最多人否决的提案的位置。

现阶段来看，未来 1-3 年内在错误处理的优化上仍然会继续僵持。

作者：煎鱼eddycjy
来源：juejin.cn/post/7381741857708752905

收起阅读 »

写了一个字典hook，瞬间让组员开发效率提高20%！！！

web

1、引言在项目的开发中，发现有很多地方（如：选择器、数据回显等）都需要用到字典数据，而且一个页面通常需要请求多个字典接口，如果每次打开同一个页面都需要重新去请求相同的数据，不但浪费网络资源、也给开发人员造成一定的工作负担。最近在用 taro + react ...

继续阅读 »

1、引言

在项目的开发中，发现有很多地方（如：选择器、数据回显等）都需要用到字典数据，而且一个页面通常需要请求多个字典接口，如果每次打开同一个页面都需要重新去请求相同的数据，不但浪费网络资源、也给开发人员造成一定的工作负担。最近在用 taro + react 开发一个小程序，所以就写一个字典 hook 方便大家开发。

2、实现过程

首先，字典接口返回的数据类型如下图所示：

其次，在没有实现字典 hook 之前，是这样使用选择器组件的：

  const [unitOptions, setUnitOptions] = useState([])



  useEffect(() => {

    dictAppGetOptionsList(['DEV_TYPE']).then((res: any) => {

      let _data = res.rows.map(item => {

        return {

          label: item.fullName,

          value: item.id

        }

      })

      setUnitOptions(_data)

    })

  }, [])



  const popup = (

    <PickSelect

      defaultValue=""

      open={unitOpen}

      options={unitOptions}

      onCancel={() => setUnitOpen(false)}

      onClose={() => setUnitOpen(false)}

    />

  )

每次都需要在页面组件中请求到字典数据提供给 PickSelect 组件的 options 属性，如果有多个 PickSelect 组件，那就需要请求多次接口，非常麻烦！！！！！

既然字典接口返回的数据格式是一样的，那能不能写一个 hook 接收不同属性，返回不同字典数据呢，而且还能缓存请求过的字典数据？

当然是可以的！！！

预想一下如何使用这个字典 hook？

const { list } = useDictionary('DEV_TYPE')



const { label } = useDictionary('DEV_TYPE', 1)



const { label } = useDictionary('DEV_TYPE', 1, '、')

从上面代码中可以看到，第一个参数接收字典名称，第二个参数接收字典对应的值，第三个参数接收分隔符，而且后两个参数是可选的，因此根据上面的用法来写我们的字典 hook 代码。

interface dictOptionsProps {

  label: string | number;

  value: string | number | boolean | object;

  disabled?: boolean;

}



interface DictResponse {

  value: string;

  list: dictOptionsProps[];

  getDictValue: (value: string) => string

}



let timer = null;

const types: string[] = [];

const dict: Record<string, dictOptionsProps[]> = {}; // 字典缓存



// 因为接收不同参数，很适合用函数重载

function useDictionary(type: string): DictResponse;

function useDictionary(

  type: string | dictOptionsProps[],

  value: number | string | Array<number | string>,

  separator?: string

): DictResponse;

function useDictionary(

  type: string | dictOptionsProps[],

  value?: number | string | Array<string | number>,

  separator = ","

): DictResponse {

    const [options, setOptions] = useState<dictOptionsProps[]>([]); // 字典数组

    const [dictValue, setDictValue] = useState(""); // 字典对应值

    

    const init = () => {

      if (!dict[type] || !dict[type].length) {

        dict[type] = [];



        types.push(type);



        // 当多次调用hook时，获取所有参数，合成数组，再去请求，这样可以避免多次调用接口。

        timer && clearTimeout(timer);

        timer = setTimeout(() => {

          dictAppGetOptionsList(types.slice()).then((res) => {

            for (const key in dictRes.data) {

              const dictList = dictRes.data[key].map((v) => ({

                label: v.description,

                value: v.subtype,

              }));

              dict[type] = dictList

              setOptions(dictList) // 注意这里会有bug，后面有说明的

            }

          });

        }, 10);

      } else {

        typeof type === "string" ? setOptions(dict[type]) : setOptions(type);

      }

    };

    

    // 获取字典对应值的中文名称

    const getLabel = useCallback(

        (value) => {

          if (value === undefined || value === null || !options.length) return "";

          const values = Array.isArray(value) ? value : [value];



          const items = values.map((v) => {

            if (typeof v === "number") v = v.toString();

            return options.find((item) => item.value === v) || { label: value };

          });

          return items.map((v) => v.label).join(separator);

        },

        [options]

     )

    

    useEffect(() => init(), [])

    useEffect(() => setDictValue(getLabel(value)), [options, value])

    

    return { value: dictValue, list: options, getDictValue: getLabel };

}

初步的字典hook已经开发完成，在 Input 组件中添加 dict 属性，去试试看效果如何。

export interface IProps extends taroInputProps {

  value?: any;

  dict?: string; // 字典名称

}



const CnInput = ({

  dict,

  value,

  ...props

}: IProps) => {

  const { value: _value } = dict ? useDictionary(dict, value) : { value };

  

  return <Input value={_value} {...props} />

}

添加完成，然后去调用 Input 组件

<CnInput

    readonly

    dict="DEV_ACCES_TYPE"

    value={formData?.accesType}

/>



<CnInput

    readonly

    dict="DEV_SOURCE"

    value={formData?.devSource}

/>

没想到，翻车了

会发现，在一个页面组件中，多次调用 Input 组件，只有最后一个 Input 组件才会回显数据

这个bug是怎么出现的呢？原来是 setTimeout 搞的鬼，在 useDictionary hook 中，当多次调用 useDictionary hook 的时候，为了能拿到全部的 type 值，请求一次接口拿到所有字典的数据，就把字典接口放在 setTimeout 里，弄成异步的逻辑。但是每次调用都会清除上一次的 setTimeout，只保存了最后一次调用 useDictionary 的 setTimeout ,所以就会出现上面的bug了。

既然知道问题所在，那就知道怎么去解决了。

解决方案： 因为只有调用 setOptions 才会引起页面刷新，为了不让 setTimeout 清除掉 setOptions，就把 setOptions 添加到一个更新队列中，等字典接口数据回来再去执行更新队列就可以了。



let timer = null;

const queue = []; // 更新队列

const types: string[] = [];

const dict: Record<string, dictOptionsProps[]> = {};



function useDictionary2(type: string): DictResponse;

function useDictionary2(

  type: string | dictOptionsProps[],

  value: number | string | Array<number | string>,

  separator?: string

): DictResponse;

function useDictionary2(

  type: string | dictOptionsProps[],

  value?: number | string | Array<string | number>,

  separator = ","

): DictResponse {

  const [options, setOptions] = useState<dictOptionsProps[]>([]);

  const [dictValue, setDictValue] = useState("");



  const getLabel = useCallback(

    (value) => {

      if (value === undefined || value === null || !options.length) return "";

      const values = Array.isArray(value) ? value : [value];



      const items = values.map((v) => {

        if (typeof v === "number") v = v.toString();

        return options.find((item) => item.value === v) || { label: value };

      });

      return items.map((v) => v.label).join(separator);

    },

    [options]

  );



  const init = () => {

    if (typeof type === "string") {

      if (!dict[type] || !dict[type].length) {

        dict[type] = [];



        const item = {

          key: type,

          exeFunc: () => {

            if (typeof type === "string") {

              setOptions(dict[type]);

            } else {

              setOptions(type);

            }

          },

        };

        queue.push(item); // 把 setOptions 推到 更新队列(queue)中



        types.push(type);



        timer && clearTimeout(timer);

        timer = setTimeout(async () => {

          const params = types.slice();



          types.length = 0;



          try {

              let dictRes = await dictAppGetOptionsList(params);

              for (const key in dictRes.data) {

                dict[key] = dictRes.data[key].map((v) => ({

                  label: v.description,

                  value: v.subtype,

                }));

              }

              

              queue.forEach((item) => item.exeFunc()); // 接口回来了再执行更新队列

              queue.length = 0; // 清空更新队列

          } catch (error) {

            queue.length = 0;

          }

        }, 10);

      } else {

        typeof type === "string" ? setOptions(dict[type]) : setOptions(type);

      }

    }

  };



  useEffect(() => init(), []);



  useEffect(() => setDictValue(getLabel(value)), [options, value]);



  return { value: dictValue, list: options, getDictValue: getLabel };

}



export default useDictionary;

修复完成，再去试试看~

不错不错，已经修复，嘿嘿~

这样就可以愉快的使用字典 hook 啦，去改造一下 PickSelect 组件

export interface IProps extends PickerProps {

  open: boolean;

  dict?: string;

  options?: dictOptionsProps[];

  onClose: () => void;

}

const Base = ({

  dict,

  open = false,

  options = [],

  onClose = () => { },

  ...props

}: Partial<IProps>) => {

  // 如果不传 dict ，就拿 options 

  const { list: _options } = dict ? useDictionary(dict) : { list: options };



  return <Picker.Column>

          {_options.map((item) => {

            return (

              <Picker.Option

                value={item.value}

                key={item.value as string | number}

              >

                {item.label}

              </Picker.Option>

            );

          })}

        </Picker.Column>

在页面组件调用 PickSelect 组件

效果：

这样就只需要传入 dict 值，就可以轻轻松松获取到字典数据啦。不用再手动去调用字典接口啦，省下来的时间又可以愉快的摸鱼咯，哈哈哈

最近也在写 vue3 的项目，用 vue3 也实现一个吧。

// 定时器

let timer = 0

const timeout = 10

// 字典类型缓存

const types: string[] = []

// 响应式的字典对象

const dict: Record<string, Ref<CnPage.OptionProps[]>> = {}



// 请求字典选项

function useDictionary(type: string): Ref<CnPage.OptionProps[]>

// 解析字典选项，可以传入已有字典解析

function useDictionary(

  type: string | CnPage.OptionProps[],

  value: number | string | Array<number | string>,

  separator?: string

): ComputedRef<string>

function useDictionary(

  type: string | CnPage.OptionProps[],

  value?: number | string | Array<number | string>,

  separator = ','

): Ref<CnPage.OptionProps[]> | ComputedRef<string> {

  // 请求接口，获取字典

  if (typeof type === 'string') {

    if (!dict[type]) {

      dict[type] = ref<CnPage.OptionProps[]>([])



      if (type === 'UNIT_LIST') {

        // 单位列表调单独接口获取

        getUnitListDict()

      } else if (type === 'UNIT_TYPE') {

        // 单位类型调单独接口获取

        getUnitTypeDict()

      } else {

        types.push(type)

      }

    }



    // 等一下，人齐了才发车

    timer && clearTimeout(timer)

    timer = setTimeout(() => {

      if (types.length === 0) return

      const newTypes = types.slice()

      types.length = 0

      getDictionary(newTypes).then((res) => {

        for (const key in res.data) {

          dict[key].value = res.data[key].map((v) => ({

            label: v.description,

            value: v.subtype

          }))

        }

      })

    }, timeout)

  }



  const options = typeof type === 'string' ? dict[type] : ref(type)

  const label = computed(() => {

    if (value === undefined || value === null) return ''

    const values = Array.isArray(value) ? value : [value]

    const items = values.map(

      (value) => {

        if (typeof value === 'number') value = value.toString()

        return options.value.find((v) => v.value === value) || { label: value }

      }

    )

    return items.map((v) => v.label).join(separator)

  })



  return value === undefined ? options : label

}



export default useDictionary

感觉 vue3 更简单啊！

到此结束！如果有错误，欢迎大佬指正~

作者：用户2885248830266
来源：juejin.cn/post/7377559533785022527

收起阅读 »

运维打工人，周末兼职送外卖的一天

职场话题

运维打工人，周末兼职送外卖的一天在那个不经意的周末，我决定尝试一份新的工作——为美团外卖做兼职配送员。这份工作对于一向规律生活的我来说，既是突破也是挑战。早晨，城市的喧嚣还未完全苏醒，空气中带着几分凉意和宁静。准备好出发时，线上生产环境出现问题，协助处理。...

继续阅读 »

运维打工人，周末兼职送外卖的一天

在那个不经意的周末，我决定尝试一份新的工作——为美团外卖做兼职配送员。这份工作对于一向规律生活的我来说，既是突破也是挑战。

早晨，城市的喧嚣还未完全苏醒，空气中带着几分凉意和宁静。准备好出发时，线上生产环境出现问题，协助处理。

收拾好后，戴上头盔，骑上踏板车，开始了自己的第一次外卖配送之旅。

刚开始，我的心情既紧张又兴奋。手机里的订单提示声是今日的任务号角。第一份订单来自一公里外的一家外卖便利店。我快速地在地图上规划路线，开启高德导航，发动踏板车，朝着目的地出发。

由于便利店在园区里面，转了两圈没找到，这是就慌张了，这找不到店咋办了，没办法赶紧问下旁边的老手骑手，也就顺利找到了，便利店，进门问老板，美团104号好了嘛？老板手一指，在架子上自己看。核对没问题，点击已达到店，然后在点击已取货。

然后在导航去收获目的地，找到C栋，找到107门牌号，紧接敲门，说您好，美团外卖到了，并顺利的送达，然后点击已送达，第一单顺利完成，4.8元顺利到手。

其中的小插曲，送给一个顾客时，手机导航提示目的地，结果一看，周围都拆了。没办法给顾客打电话，加微信确认位置具体在哪里，送达时，还差三分钟，这单就要超时了。

配送过程中，我遇到了第一个难题：找不到店家在哪里，我的内心不禁生出些许焦虑。但很快，我调整心态，不懂不知道的地方，需要多多问人。

紧接着，第二份、第三份订单接踵而至。每一次出发和到达，每一条街道和巷弄，我开始逐渐熟悉。

日落时分，我结束了一天的工作。虽然身体有些疲惫，但内心充满了前所未有的充实感。这份工作让我体验到了不一样的人生角色，感受到了城市节奏背后的种种辛劳与甘甜。

周末的兼职跑美团外卖，对我来说不仅是一份简单的工作，更是一段特别的人生经历。它教会了我坚持与责任，让我在忙碌中找到了属于自己的节奏，在逆风中学会了更加珍惜每一次到达。

最后实际周六跑了4个小时，周天跑了7个小时，一共跑了71公里，合计收获了137.80，已提现到账。

作者：平凡的运维之路
来源：juejin.cn/post/7341669201010425893

收起阅读 »

为了解决小程序tabbar闪烁的问题，我将小程序重构成了 SPA

web

（日落西山，每次看到此景，我总是会想到明朝（明朝那些事儿第六部的标题，日落西山）) 前言几个月前，因工作需求，我开发了一个小程序，当时遇到了一个需求，是关于tabbar权限的问题。小程序的用户分两种，普通用户和vip用户，普通用户tabbar有两个，vip...

继续阅读 »

（日落西山，每次看到此景，我总是会想到明朝（明朝那些事儿第六部的标题，日落西山）)

前言

几个月前，因工作需求，我开发了一个小程序，当时遇到了一个需求，是关于tabbar权限的问题。小程序的用户分两种，普通用户和vip用户，普通用户tabbar有两个，vip用户小程序下面的tabbar有五个。

因为涉及自定义tabbar的问题，所以官方自带的tabbar肯定就不能用了，我们需要自定义tabbar。官方也提供了自定义tabbar的功能。

官网自定义tabbar

官网地址：基础能力 / 自定义 tabBar (qq.com)

{

  "tabBar": {

    "custom": true,

    "list": []

  }

}

就是需要在 app.json 中的 tabBar 项指定 custom 字段，需要注意的是 list 字段也需要存在。

然后，在代码根目录下添加入口文件:

custom-tab-bar/index.js

custom-tab-bar/index.json

custom-tab-bar/index.wxml

custom-tab-bar/index.wxss

具体代码，大家可以参考官网案例。

需要注意的是每个tabbar页面 / 组件都需要在onshow / show 函数中执行以下函数，否则就会出现tabbar按钮切换两次，才会变成选中色的问题。

      if (typeof this.getTabBar === 'function' &&

        this.getTabBar()) {

        this.getTabBar().setData({

          selected: 0     // 第n个tabbar页面就填 n-1

        })

      }

接下来就是我的思路

我在 custom-tab-bar/index.js 中定义了一个函数，这个函数去判断当前登录人是否为vip，如果是就替换掉tabbar 的数据。

那么之前每个页面的代码就要写成这样

      if (typeof this.getTabBar === 'function' &&

        this.getTabBar()) {

        this.getTabBar().change_tabbar_list()

        this.getTabBar().setData({

          selected: 0   // 第n个tabbar页面就填 n-1

        })

      }

ok，我们来看一下效果。注意看视频下方的tabbar，每个页面，第一次点击的时候，有明显的闪烁bug。（大家也可以参考一下市面上的小程序，小部分的小程序有这个闪烁问题，大部分的小程序没有这个闪烁的问题（如：携程小程序））

bug产生原因

那么我们就要去思考了，为什么人家的小程序没有这个bug呢？

想这个问题前，要先去想这个bug是怎么产生的，我猜测是每个tabbar页面都有个初始化的过程，第一次渲染页面的时候要去重新渲染tabbar，每个页面的tabbar都是从0开始渲染，然后会缓存到每个页面上，所以第二次点击就没有这个bug了。

解决tabbar闪烁问题

为了解决这个问题，我想到了SPA ，也就是只留一个页面，其他的tabbar页面都弄成组件。

效果展示

已经解决，tabbar闪烁的问题。

代码思路，通过wx:if 控制组件的显示隐藏。

源码地址：gitlab.com/wechat-mini…

https克隆地址：gitlab.com/wechat-mini…

写在最后

1、我也是在网上见过别人的一些评论，说如果将小程序重构成这种单页面，会有卡顿问题，我目前没有发现这个问题，可能是我做的小程序功能比较少。

2、至于生命周期，将页面切换成组件后，页面的那些生命周期也肯定都不能使用了，只能用组件的生命周期，我之前开发使用组件的生命周期实现业务逻辑也没什么问题。触底加载这些也只能换成组件去实现了。

3、小程序最上面的标题，也可以使用以下代码来实现。就是在每个组件初始化的时候要去执行下列代码。

            wx.setNavigationBarTitle({

                title: '',

              });

作者：楚留香Ex
来源：juejin.cn/post/7317281367111827475

收起阅读 »

程序员真的很死板很无聊吗？

职场话题

你的生活快乐吗？如果把工作和生活10等分，你会怎么分配你的时间？故事背景前几天随手分享了一个关于我每天早上吃的补充剂的照片，没想到有很多小伙伴留言反馈，着实挺出乎我意料不禁让我想起一句自黑的老梗：想结婚找程序员，钱多话少死的早，虽然是调侃，但是也反映...

继续阅读 »

你的生活快乐吗？如果把工作和生活10等分，你会怎么分配你的时间？

故事背景

前几天随手分享了一个关于我每天早上吃的补充剂的照片，没想到有很多小伙伴留言反馈，着实挺出乎我意料

不禁让我想起一句自黑的老梗：想结婚找程序员，钱多话少死的早，虽然是调侃，但是也反映了大众对程序员团体的刻板映象确实很糟糕。

加上我身边很多同行业的同事这个毛病那个毛病的，30出头就脂肪肝...这也让我产生了一些思考：

我们这个行业的从业者，在到了25岁、30岁、35岁、40岁的生活状况，健康状况分别是怎么样的？

会运动吗？吃的健康吗？身体还好吗？

是不是真的像网上说的一样，程序员很无聊，很宅，死板？

所以我真的很好奇，大多数开发的生活状态是怎么样的，今天我分享一下我作为一个开发的日常，想看看我的生活是不是具有普遍性。（多图预警）

自我介绍

先来自我介绍一下，我叫dev，今年32岁（中年男人了），是个从业快7年的前端，主攻 React 技术栈，目前在一家ToG的公司做架构师。现在一边写基建一边在带人，基本脱离了业务代码的编写（偶尔）。

工作之余会写写文章，发发视频，阐述一些我认知的价值观和能提升生活幸福度的方法。下面是我平时的生活状态，兴趣比价广泛，基本上喜欢什么干什么（人生苦短及时行乐）：

喜欢旅游，尤其那些山山水水，它会让我的内心平静

喜欢画画，从初中开始，课本就是我的绘画本

会弹吉他，大学玩过乐队，也受邀在很多地方表演过

目前喜欢上了popping，因为它很酷【在学】

因为很爱健康方面的知识，2024年准备考健康管理师

养生日常

7点起床，7.30做饭

早上7点起床，洗漱完之后，喝一杯温水，7:30 准备今天的伙食。（因为公司提供早餐，周末会自己做）

我不太喜欢吃外卖，因为我感觉很多外卖的食材不新鲜，而且大多为了可以放的时间久一点，盐分含量过高了！这是我每天早上早起做饭的动力之一。

9点到公司，开始工作吃早饭

早餐一般我会搭配文章开头的补剂一起吃。上班的时间我就快速跳过了，应该大部分时间和大家一样：

9点30-12点：工作时间

12点-1点：中饭时间

1点-1点30：午休半小时

1点30-5点30：工作时间

5点30下班

一般我会在公司待到6点半，因为我习惯6点准时吃饭，吃完之后再回来打个卡下班。常规操作。

下班之后我的安排一般是：周一8点撸铁，周三周五都有 popping 课，周二周四一般就在家写点东西，或者拍点东西，看看书啥的学习一下。

周末

周六外出

周五一到，令人兴奋的周末就要来了。一般周四周五就会大概想好周六的行程。有时候三五好友，有时候一个人，找个偏僻的乡村，搭个帐篷，架个躺椅，平静的过一天～（手机关机，啥都别来烦我）

周日创作

一般很少会连续两天出去玩儿，所以周日会安排自己学习一些新的东西，比如最近就在备考健康管理师，周日基本上午都在复习，周日下午就灵活安排，可能刷刷剧，撸撸猫，兴致来了晚上也会去上课，因为周日晚上也有一节课。
灵感来了也会写写文章，不管技术型的或者是生活向的，想到啥写啥，我很喜欢这种自由创作的感觉。让我有对生活的掌控感。

总结

以上就是我的日常生活，最近很喜欢一个成语：向死而生。我认为人到了一定年纪之后就会从学生变为布道者。写这篇文章的目的也很简单，希望能通过自己的生活态度告诉外界，我们也懂生活，我们也有自己对于生活的态度。

当我们光着屁股来到这个世界上，死的时候除了我们这一辈子的经历也是光着屁股走。所以我希望死的那一天，回顾我的一生，能很有底气的告诉自己：这一生无憾了！

这些年不断的犯错，不断的纠正。从以前天上地下唯我独尊的摇滚少年，到现在成熟低调的中年男人。总结下来，我发现想要的生活其实很简单：

有爱我和我爱的人

有我喜欢做的事情

身体健康（能比同龄人看起来年轻10岁我就心满意足了👀）

希望这篇文章能帮到你重新认识生活，评论区也可以留下你对自己生活的态度，和你认为对自己生活的掌控感有多少？

作者：dev
来源：juejin.cn/post/7373955162127876123

收起阅读 »

“请杀死自己的学生思维”

职场话题

Hello，大家好，我是 Sunday。昨天在B站上看到了一个视频叫做请“杀死”自己的学生思维这不禁让我想起之前写过的一篇文章我们应避免感动自己的无效学习！在现在 “内卷” 日益严重的大行情之下，很多同学都会充满的焦虑，生怕自己一个不小心就会被淘...

继续阅读 »

Hello，大家好，我是 Sunday。

昨天在B站上看到了一个视频叫做 请“杀死”自己的学生思维

这不禁让我想起之前写过的一篇文章我们应避免感动自己的无效学习！

在现在 “内卷” 日益严重的大行情之下，很多同学都会充满的焦虑，生怕自己一个不小心就会被淘汰掉。从而开始学习很多很多的内容，期望可以通过这种方式来 “安慰自己”，告诉我已经很努力了，我不会被淘汰。

可是很多时候，这种无目标，无结果的努力，其实是毫无价值的！

什么是学生思维

“什么是学生思维” 并没有一个明确的定义。我个人认为，所谓的学生思维指的是：期望通过 “按部就班” 的努力，来达到 “超过大多数人” 的结果

回顾下我们的学生生涯：每天的课程是固定的、学习的知识是固定的、什么时候考试是固定的、甚至考试的内容是什么也是固定的。几乎所有的一切都是固定的

所以，我们只需要 “按部就班” 的走，学习固定的内容，掌握固定的知识，就可以了。

因为，所有的人学习的内容都一样。所以，如果想要超过大多数人怎么办呢？

那就只剩下一个办法了， 卷！！！

卷学习时长、卷补习班、卷做题，最重要的是 父母、老师也告诉你这样是对的，因为 TA们在工作中也是这么做的。

从而让我们认为 卷是常态，想要超过大多数人，获得排名（注意是排名而不是成绩）的靠前，那么就 必须要比别人卷！

最可怕的是 在学生时代，这样做是对的！ 只要你足够卷，那么你就可以获得更好的排名，把其他的人卷下去。

但是，这样的方式当你进入到社会中，你会发现 它好像失效了！

我们曾经亲眼看到过很多特别努力的同事依然免不了失业的结局，就好像前几天我写的这篇文章一样跟一位 40+ 岁的同学沟通之后，差点泪崩

所以，当你进入职场 “请杀死自己的学生思维”

建立全新的职场思维体系

“杀死自己的学生思维” 是一件非常难的事情。因为 过去几十年的教育和经历都告诉我们：好好学习、好好上班、多听老板的话、吃亏是福！

几十年的固化思维是很难在一朝一夕之间改变的。但是，只要你开始做了，那么就比不做好。

1：工作只是利益的结合，天下没有不散的宴席

最近这两年，公司裁员已经不是一个新鲜的话题了。

上班的时候，老板说：“你要把公司当家”。裁员的时候，老板说：“不努力的就不是我兄弟”

所谓的工作，本质上就是利益的结合。你需要一份工作赚钱，老板需要人帮他赚更多的钱，仅此而已。

当一份关系通过利益进行捆绑时，那么通常就不是那么稳定了！

当一方的利益无法得到保证时，离开就是一个必然的结果。跳槽如是，裁员亦如是。

所以，把工作当成一场“宴席”。虽然“天下没有不散的宴席”，但是当一场宴席结束后，你才会迎来新的机会。

2：努力适应变化，生活不是考试，不需要排名

这个社会中唯一不变的就是一直在变化。这是与学生时代的最大不同。

诚如前面所说，学生时代几乎所有的一切都是固定的。但是，在生活中一切都是 瞬息万变 的。

进入社会，我们才发现生活远不止上学、考试这些固定的轨道。工作环境、市场需求、个人生活状况，甚至全球的经济和政治局势，都在不断变化。我们面对的已不是一张张试卷，而是一个个现实的挑战和机遇。我们需要学会适应这些变化，在不确定性中寻找方向和机会。

同时，生活也不是考试，没有所谓的得分，也不存在所谓的正确答案。

跟大家说一个某同学的故事，这位同学我们叫他小A：

小A 之前是某英语培训机构的老师。K12 被禁止后失业。

因为英语很好，同时身边有做开发的朋友，所以进到私教训练营里学习，想要做前端开发的岗位。

但是，因为之前没有编程经验，所以学习速度并不快，预计需要 5 个月的学习周期。

一次无意中，小A 了解到小区中很多小孩子都有英语学习的需求。就过来问我：“Sunday 老师，你觉得我能不能帮小朋友学习英语，这样也可以获取一些收入。”

我帮他出了一整套的方案，那一个月的时间，我们针对小A 的培训需求进行了很多次的沟通。最后大家猜怎么着？

小A 成功的做起来了一个小范围的英语学习班，每个月的收入甚至远超之前工作的收入。

我们每个人都有很多的选择。就如小A 一样 “做开发”，“做老师”，“做培训”。

以上的选择都可以是正确的，也可能都是错误的。生活没有标准答案，每个人都有自己的独特路径和目标。

3：不要妄图规划未来，先把当下的事情做好

很多同学喜欢规划未来，这个并没有太大的意义。

比如：很多同学还没有找到工作的时候，就在担心 35 岁之后，如果失业了怎么办？这无疑是一种杞人忧天的想法。

未来的事情不可预测。很多鸡汤书籍都在告诉大家需要思考未来的情况，从而安排未来的计划：3 年计划、5 年计划甚至是 10 年计划。

乍一听，好像很有道理的样子。但是现实却告诉我们，哪怕是 3 天之后的情况，我们都预测不了。

过分的思考未来，会让我们忘记当下。就像之前的躺平文中所说：“人总会死，那么为什么还要努力呢？（注意：这是不对的）”。这甚至算是一个 “百年计划” 了。

所以，先解决当下的问题 吧，这才是最重要的！当下都解决不了，谈什么未来？

总结

无论你现在处于生活中的哪一个阶段，是痛苦着，还是快乐着。我都希望你可以摆脱原有的学生思维，尝试适应变化，找到自己独特的路径和目标 从而获得自己想要的幸福。

作者：程序员Sunday
来源：juejin.cn/post/7381781956727357452

收起阅读 »

程序员都在用哪些神器？

职场话题

工作中，我们有时候往往需要合理利用工具为我们提高一定的工作效率。利用包罗万象的浏览器搜索想要的资源已经是司空见惯了。既然浏览器已经成为每一位电脑工作者的首要工具，那必然会有老六的出现，在我们的浏览器上增加广告，限制资源访问的手段，逼迫我们不得不妥协或者充值满...

继续阅读 »

工作中，我们有时候往往需要合理利用工具为我们提高一定的工作效率。利用包罗万象的浏览器搜索想要的资源已经是司空见惯了。

既然浏览器已经成为每一位电脑工作者的首要工具，那必然会有老六的出现，在我们的浏览器上增加广告，限制资源访问的手段，逼迫我们不得不妥协或者充值满足他们。

一名电脑从业者，想要一台干净的办公电脑环境可以说是一份奢求。我也观察其他部门同事们的电脑，电脑时不时弹出小电影片段，一刀 9999 的弹窗，可以说是皮到家了，不解释一下都以为平时就干这些事。

所以，我这里分享几款程序员常用的神器，即可应付老六行为，也可以方便我们摸鱼以及日常的工作使用。

AdGuard 拦截器

我们工作时候难免搜索一些紧急的关键信息，搜索过程中却时不时弹出亮眼的广告，甚至出现更加过分的花屏广告。

一怒之下想点击关闭窗口，却发现关闭窗口异常的难点，甚至阴差阳错点进广告内容，选择加入他们，小紧张的和旁边观看的同事解释我并没有干这种事情。

AdGuard 广告拦截器，一款无与伦比的广告拦截扩展，用以对抗各式广告与弹窗。可以拦截所有网站的广告。

拦截所有广告，包括：视频广告，各种媒体广告，例如视频广告，插播广告和浮动广告，令人讨厌的弹窗横幅广告和文字广告。

加速页面载入，节省带宽，屏蔽广告和弹窗。

拦截各种软件，广告软件和拨号安装程序（可选）。

一旦安装了这款神器，我是万万没想到多流氓的网站都能够乖巧的显示它本应该显示的内容，不夹杂花里胡哨。眼不见为净，气不过难不成咱还躲不起，还给自己一个优质的工作环境。

Global Speed

作为当代视频冲浪儿，我们在闲暇时刻总是难免观看一些视频内容来打发时间，比如哔哩哔哩，腾讯视频，百度网盘，爱奇艺等。

有些视频内容往往是冗长且枯燥的，以及万恶的资本早已经捕捉到群体的口味，通常会增加一些不知是否趣味的广告。这时我们往往万般无奈等待着播放完，或者跳过观看。

如果我们使用 Global Speed 工具，我们可以躲避那些没有充值会员时候给我们增加冗长的广告，使得视频播放速度提高至 16 倍进行躲闪。它几乎支持所有的视频平台。

也就意味着 100 秒的广告，我们 8 秒就过完了。

Imagus

在使用浏览器逛一些网站和商城时，需要查看一些视频和图片，我们往往会选择点击进去查看大图。且有时候查看大图时，需要选择登录或者 vip 才能查看大图的权限。

Imagus 插件，很好的解决了多点一下的问题，他可以停留在页面上不去点击进去直接鼠标悬停之后可查看大图效果。

他的作用是鼠标指针悬停在链接或缩略图上时直接在当前页面的弹出视图上显示这些图片、HTML5 视频/音频和内容专辑。

Picture-in-Picture Extension

这款画中画，我只能说是摸鱼神器了。在工作中，往往会趁着老板不注意或者躲避监控范围偷偷地摸鱼。

时不时看一些好玩的视频，或者看看电竞直播，但又不敢夸张全屏观看，得给足老板的面子。所以我们会选择画中画观看，蜷缩在屏幕的一个小筐里进行观看，又不引人注意，也不影响手头的工作。

使用 Picture-in-Picture 工具，我们既可以一边工作一边画中画观看自己想看的小视频，还能随意所动位置以及设置画面大小，别提多惬意。

购物党自动比价工具

我所认识的程序员群体里，有 10 个程序员里有 7-8 个都是会过日子的。不管是淘淘自己喜爱的电子产品还是生活必需品里，他们往往追求极致的性价比。在购买自己喜爱的电子产品时，往往会搜罗多个电商平台进行比价，以及寻求降价机会。

而且，在面对自己的女神或者妹妹赠送礼物时，会徘徊在既要给出大方又要价格合理的礼品，毕竟不能不失对方的面子也不能让自己陷入窘迫的险境。如今的环境里寸金都不是大风刮来的。

购物党自动比价工具，往往是一些程序员必备的工具。浏览商品页面时，自动查询 180 天历史价格、比较同款商品的全网最低价、提示促销和隐藏优惠券、一旦降价还能通过微信提醒你，海淘、二手房游戏平台也能比价。

当我们搜索一款商品时，左上角会自动查找各个平台的价格，价格的走势，以及优惠券的信息。是能够极大得缩减我们淘尚品的时间。

SuperCopy 超级复制

我们得益于互联网包罗万象，总是能够通过检索得到我们所需要的信息，使得我们尽管是一名程序员，也容易陷入 CV（复制粘贴）工程师的身份。

总是有老六的出现，好不容易搜索到关键信息，结果一复制，温馨的弹框告诉我们需要登录或者充值 VIP。

气的人直跺脚，我们还拿他没办法，老板微信里三番五次催出我们好了没有，但我们又徘徊在付费工作的僵局。

SuperCopy 超级复制，这款插件绝对能够治理那些老六。

一键破解禁止右键、破解禁止选择、破解禁止复制、破解禁止粘贴，启用复制，启用右键，启用选择，启用粘贴。

超级复制 SuperCopy ，在禁止复制、禁止右键、禁止选择的站点，一键复制，一键粘贴，一键选择，启用右键，启用复制，启用选择，启用粘贴。

主要功能：解除禁止复制、解除禁止右键、解除禁止选择、解除禁止粘贴。

如何安装

方式一： 如果您有科学上网，可以直接进入谷歌商城，依次搜索插件名称即可安装。

谷歌商城地址：chromewebstore.google.com/

如您没有科学上网，您可在公众号后台会回复 【科学上网】 即可获取工具。如您有使用问题，可在后台加作者联系方式，可以进行指导和咨询。

方式二： 您可以进入插件小屋，搜索插件名称进行下载。

插件小屋：http://www.chajianxw.com/

下载之后点击谷歌浏览器设置，进入扩展程序界面。

您可以将刚刚下载的插件压缩包拖拽到扩展程序界面，即可使用。

作者：程序员小榆
来源：juejin.cn/post/7346119032524357642

收起阅读 »

如何将微信小程序从WebView迁移到Skyline

web

什么是 Skyline 微信小程序新的渲染引擎，使用更加高效的渲染管线，提供更好的性能和全新的交互动画体验。具体可以查阅官网介绍将开发者工具切换成 Sykline 模式调试基础库切到 2.30.4 或以上版本确保右上角 > 详情 > 本地...

继续阅读 »

什么是 Skyline

微信小程序新的渲染引擎，使用更加高效的渲染管线，提供更好的性能和全新的交互动画体验。

具体可以查阅官网介绍

将开发者工具切换成 Sykline 模式

调试基础库切到 2.30.4 或以上版本

确保右上角 > 详情 > 本地设置里的开启 Skyline 渲染调试、启用独立域进行调试选项被勾选上

确保右上角 > 详情 > 本地设置里的将 JS 编译成 ES5 选项被勾选上

使用 skylint 工具迁移



npx skylint

使用过程中可能会出现文件未找到错误，例如

原因就是使用绝对路径 <import src="/components/chooserList/index.wxml" />导入模块，而 skylint 无法找到该文件，需要修改为相对路径 <import src="../../components/chooserList/index.wxml" />导入模块

有几种提示不是很准确，可以评估下:

@position-fixed 不支持 position: fixed：如果你根据不同 renderer 兼容，则会导致该提示一直存在

@no-pseudo-element 不支持伪元素: 目前对已经支持的 ::before 和 ::after 也会进行提示

手动迁移

在 app.json 配置



{

"lazyCodeLoading": "requiredComponents", // 开启按需注入

    "rendererOptions": {

        "skyline": {

            "defaultDisplayBlock": true // skyline 下节点默认为 flex 布局，可以在此切换为默认 block 布局

        }

    }

}

在 page.json 配置



{

    "renderer": "skyline", // 声明为 skyline 渲染，对于已有的项目，建议渐进式迁移，对于新项目，直接全局打开，在 app.json 里进行配置

    "componentFramework": "glass-easel", // 声明使用新版 glass-easel 组件框架

    "disableScroll": true, // skyline 不支持页面全局滚动，为了使之与WebView保持兼容，在此禁止滚动

    "navigationStyle": "custom" // skyline 不支持原生导航栏，为了使之与WebView保持兼容，并且自行实现自定义导航栏

}

skyline 不支持页面全局滚动，如果需要页面滚动，在需要滚动的区域使用 scroll-view 实现



<scroll-view type="list" scroll-y style="flex: 1; width: 100%; overflow: hidden;"></scroll-view>



page {

    display: flex;

    flex-direction: column;

    height: 100vh;

}

skyline 渲染模式下 flex-direction 默认值是 column，为了使之与WebView保持兼容，需要在 flex 布局里将 flex-direction 默认值改为 row

在真机上调试 skyline 渲染模式

小程序菜单 > 开发调试 > Switch Render，会出现三个选项，说明如下：

Auto ：跟随 AB 实验，即对齐小程序正式用户的表现

WebView ：强制切为 WebView 渲染

Skyline ：若当前页面已迁移到 Skyline，则强制切为 Skyline 渲染

常见问题

position: fixed 不支持

需要将



<view class="background"></view>



.background {



    position: fixed;



}

修改为



<root-portal>



    <view class="background"></view>



</root-portal>



.background {



    position: absolute;



}

如果无法做到适配，则可以根据不同 renderer 兼容



<view class="position {{renderer}}"></view>



.position {

    position: fixed;

}



.position.skyline {

    position: absolute;

}



Page({

    data: {

        renderer: 'webview'

    },



    onLoad() {

        this.setData({

            renderer: this.renderer,

        })

    },

})

不支持 Canvas 旧版接口

Skyline 渲染模式下，旧版 Canvas 绘制图案无效（使用 wx.createCanvasContext 创建的上下文）

在真机中图片的 referer 丢失

测试结果如下:

使用 WebView 渲染 Image，请求的 header 是：



{

    host: 'xxx',

    connection: 'keep-alive',

    accept: 'image/webp,image/avif,video/*;q=0.8,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5',

    'user-agent': 'xxx',

    'accept-language': 'zh-CN,zh-Hans;q=0.9',

    referer: 'https://servicewechat.com/',

    'accept-encoding': 'gzip, deflate'

}

使用 Skyline 渲染 Image，请求的 header 是:



{



    'user-agent': 'Dart/2.16 (dart:io)',

    'accept-encoding': 'gzip',

    host: 'xxx'

}

官方 Demo

可以参考官方Demo学习使用 Skyline 的增强特性，比如 Worklet 动画、手势系统等，但在首次下载编译时，会遇到【交互动画】页面为空的问题，主要原因是该页面是由 TypeScript 写的，编译成 JavaScript 需要开启工具内置的 TypeScript编译插件，需要在project.config.json project.config.json 配置:



setting.useCompilerPlugins: ["typescript"]

参考

从 WebView 迁移

Skylint：Skyline 小程序迁移工具

miniprogram-demo

作者：不二先生不二
来源：juejin.cn/post/7262656196854644792

收起阅读 »

小程序实现无感登录+权限分配

web

djngo开发：小程序实现无感登录+权限分配由来最近开发一个预约系统，需要区分普通用户和工作人员。由于账号密码/短信验证过于繁琐，因而选择记录openid实现无感登录。（基本小程序都这样操作）同时事先在数据库中录入客户手机号，即可在用户登录时根据有无手机...

继续阅读 »

djngo开发：小程序实现无感登录+权限分配

由来

最近开发一个预约系统，需要区分普通用户和工作人员。由于账号密码/短信验证过于繁琐，因而选择记录openid实现无感登录。（基本小程序都这样操作）

同时事先在数据库中录入客户手机号，即可在用户登录时根据有无手机号来区分普通用户和工作人员。这样在项目交付时，工作人员和普通用户一样可以直接登录无感登录小程序

1. 开发思路

微信的openid是一种唯一标识用户身份的字符串

用户登录小程序，通过手机号快速验证组件获取动态令牌code，后端向微信服务器发送get请求并带上code获取每个用户唯一的openid，然后记录到mysql中，并签发token。该openid就是登录小程序的唯一凭证。

2.简单实现

获取openid，如果通过openid查不用户，就自动新建用户，并返回token。

#####LoginView###########



code = request.data.get("code")

appid = appid # 微信小程序的appid

appsecret = "xxxxxxxx" # 微信小程序的密钥,登录微信公众平台即可获取

# 获取openid和session_token

querystring = {"appid":appid,"js_code":code,"secret":appsecret,"grant_type":"authorization_code"}

jscode2session = requests.get('https://api.weixin.qq.com/sns/jscode2session',params=querystring)

if not jscode2session.json().get("errcode"):

            data = jscode2session.json()

            ########拿到openid#########

            openid=data.get("openid")

            #######去数据库比对，如果通过openid查到用户并且未被禁用，就新建##########

            try:

                user = models.UserInfo.objects.get(openid)

                if user.is_deleted: # 检查用户是否被禁用

                    return ErrorResponse(msg='用户已被禁用，无法登录',data=data,code=302)

            except models.UserInfo.DoesNotExist: 

               models.UserInfo.objects.create()

3.更进一步：通过手机号来区别普通用户和工作人员

openid虽然做到的唯一性验证，但是当用户数量庞大时，该如何区分用户角色：

一：手动在后台根据已有用户分配权限

二：登录时根据某一标识区分角色

方法一显然不靠谱，因为用户至少会超过1000人，方法二需要额外标识，显然手机号最合适。

3.1 前端获取手机号的动态令牌

小程序提供了手机号快速验证组件，方便我们获取手机号

把bindgetphonenumber 事件回调中的动态令牌code传到开发者后台

  <view class="title">欢迎来到广盈预约</view>

  <view class="card">

    <view class="button">快捷登录</view>

    <button

      style="opacity: 0"

      class="bottom-button"

      open-type="getPhoneNumber|agreePrivacyAuthorization"

      bindgetphonenumber="getrealtimephonenumber"

      bindagreeprivacyauthorization="handleAgreePrivacyAuthorization"

    >

      同意隐私协议并授权手机号注册

    </button>

  </view>

</view>

Page({

  getPhoneNumber (e) { console.log(e.detail.code)  // 动态令牌 }

})

注意：如果你想获取用户手机号就必须添加用户授权《隐私保护协议》bindagreeprivacyauthorization，否则小程序无法上线

3.2 后端带着动态令牌去微信服务器获取手机号

简单来说就是用户登录时数据库中没有手机号对应的用户，后端就会自动建立一个账号，并分配权限为普通用户，然后直接登录。

这样的话，只需要第一次登录时获取手机号，以后登录就可以直接进入系统。

class RegisterView(APIView):  

    authentication_classes = []

    permission_classes = []

    def getmobile(self,appid,code):

        """获取用户的手机号"""

        try:

            appsecret = "cxxxxxxxxx"

            querystring = {"appid":appid,"secret":appsecret,"grant_type":"client_credential"}

            response = requests.get('https://api.weixin.qq.com/cgi-bin/token',params=querystring)

            access_token = response.json().get("access_token")

            querystring = {"access_token":access_token}

            headers = {"content-type": "application/json"}

            payload = {"code":code}

            mobile =requests.post(f"https://api.weixin.qq.com/wxa/business/getuserphonenumber?access_token={access_token}",json=payload,headers=headers)

            return mobile.json().get('phone_info').get('phoneNumber')

        except Exception as e:

            return 





    def post(self, request):   

        unionid =request.data.get("unionid")

        nickname =request.data.get("nickname")

        openid = request.data.get("openid")

        code = request.data.get("code")

        appid = request.data.get("appid")



        mobile = self.getmobile(appid=appid,code=code)

        if not mobile:

            return ErrorResponse(msg="手机号获取失败")



        defaults = {

            "openid":openid,

            "unionid":unionid,

            "mobile":mobile,

            "nickname":nickname,

        }



        """这条语句将查找一个符合mobile=mobile条件的记录,如果找到就更新 defaults中的字段 ,否则就创建

        注意： 查询的条件必须是唯一的，否则会造成多条数据返回而报错，这个逻辑同 get() 函数。

        注意： 使用的字段，没有唯一的约束，并发的调用这个方法可能会导致多条相同的值插入。

        """

        models.UserInfo.objects.update_or_create(mobile=mobile,defaults=defaults) 

        models.User_GZH.objects.get_or_create(unionid=unionid, defaults={'unionid':unionid})

        return DetailResponse()

作者：大海前端
来源：juejin.cn/post/7293177336488804391

收起阅读 »

进程还在，JSF接口不干活了，这你敢信？

Java

1、问题背景：应用在配合R2m升级redis版本的过程中，上游反馈调用接口报错，RpcException：[Biz thread pool of provider has been exhausted]，通过监控系统和日志系统定位到现象只出现在一两个节点，并...

继续阅读 »

1、问题背景：

应用在配合R2m升级redis版本的过程中，上游反馈调用接口报错，RpcException：[Biz thread pool of provider has been exhausted]，通过监控系统和日志系统定位到现象只出现在一两个节点，并持续出现。第一时间通过JSF将有问题的节点下线，保留现场，业务恢复。

报错日志如下：

24-03-13 02:21:20.188 [JSF-SEV-WORKER-57-T-5] ERROR BaseServerHandler - handlerRequest error msg:[JSF-23003]Biz thread pool of provider has been exhausted, the server port is 22003

24-03-13 02:21:20.658 [JSF-SEV-WORKER-57-T-5] WARN BusinessPool - [JSF-23002]Task:com.alibaba.ttl.TtlRunnable - com.jd.jsf.gd.server.JSFTask@0 has been reject for ThreadPool exhausted! pool:80, active:80, queue:300, taskcnt: 1067777

2、排查步骤：

从现象开始推测原因，系统启动时，会给JSF线程池分配固定的大小，当线程都在工作的时，外部流量又打进来，那么会没有线程去处理请求，此时会有上述的异常。那么JSF线程在干什么呢？

1）借助SGM打印栈信息

2）分析栈信息

可以用在线分析工具：spotify.github.io/threaddump-…

2.1）分析线程状态

通过工具可以定位到JSF线程大部分卡在JedisClusterInfoCache#getSlaveOfSlotFromDc方法，如图：

2.2）分析线程夯住的方法

getSlaveOfSlotFromDc在方法入口就需要获取读锁，同时在全局变量声明了读锁和写锁：

此时对问题有一个大体的了解，大概推测：getSlaveOfSlotFromDc是获取redis连接池，该方法入口处需要获取读锁，由于读锁之间不会互斥，所以猜测有业务获取到写锁后没有释放。同时读锁没有设置超时时间，所以导致杰夫线程处理业务时卡在获取读锁处，无法释放。

2.3）从业务的角度分析持有写锁的逻辑

向中间件研发寻求帮助，经过排查，定位到有个更新拓扑的定时任务，执行时会先获取写锁，根据该消息，定位到任务的栈信息：

代码截图：

图1

图2

图3

从日志验证：日志只打印更新拓扑的日志，没有打印更新成功的日志，且02:20分以后r2m-topo-updater就不在打印日志

2.4）深入挖掘原因

虽然现象已经可以推测出来，但是对问题的原因还是百思不得其解，难道parallelStream().forEach存在bug？难道有远程请求，没有设置超时时间？...

经过查找资料确认，如果没有指定，那么parallelStream().forEach会使用ForkJoinPool.commonPool这个默认的线程池去处理任务，该线程池默认设置（容器核心数-1）个活跃线程。同时caffeine数据过期后会异步刷新数据，如果没有指定线程池，它默认也会使用ForkJoinPool.commonPool()来执行异步线程。那么就有概率出现获取到写锁的线程无法获取执行权，获取执行权的线程无法获取到读锁。

2.5）验证

3个ForkJoinPool.commonPool-worker的确都夯在获取redis连接处，线程池的活跃线程都在等待读锁。

本地caffeine缓存没有设置自定义线程池

topo-updater夯在foreach业务处理逻辑中

3.复盘

1）此问题在特定的使用场景下才会小概率出现，非常感谢中间件团队一起协助定位问题，后续也将异步更新拓扑改为同步处理。

2）Java提供了很多异步处理的能力，但是异常处理也代表需要开启线程或者使用共用的线程池，也需要注意。

3）做好监控，能第一时间发现问题并处理问题。

作者：京东科技田蒙

来源：京东云开发者社区

作者：京东云开发者
来源：juejin.cn/post/7379831020496715813

收起阅读 »

通过代码实现 pdf 文件自动盖章

Java

序言在数字化时代，电子文档的安全性和真实性越来越受到重视。电子印章作为一种数字化的身份验证工具，已经成为确保文档合法性和不可篡改性的重要手段。然而，传统的电子印章往往需要人工操作，不仅效率低下，而且在处理大量文件时容易出错。为了解决这一问题，自动化地给PDF文...

继续阅读 »

序言

在数字化时代，电子文档的安全性和真实性越来越受到重视。电子印章作为一种数字化的身份验证工具，已经成为确保文档合法性和不可篡改性的重要手段。然而，传统的电子印章往往需要人工操作，不仅效率低下，而且在处理大量文件时容易出错。为了解决这一问题，自动化地给PDF文件盖电子章成为了一个迫切的需求。本文将详细介绍，如何通过 .net 程序实现这一功能，废话不多说，步入正题

Nuget 包

本文的核心包为：

iTextSharp，用它来操作 pdf 文件非常方便，具体的用法这里不多赘述，请参考官网
DynamicExpresso，一个非常好用的动态表达式解析工具包



  Include="DynamicExpresso.Core" Version="2.16.1" />

  Include="iTextSharp" Version="5.5.13.3" />

  Include="Newtonsoft.Json" Version="13.0.3" />

素材准备

本案例用到的素材包括：用于测试的 pdf 文件一个，模拟电子章图片一张，以及盖章配置文件，文件内容如下：

[

  {

    "SignType" : "image",//素材类型，image表示图片素材，text 表示文本素材

    "LastPage" : true,//是否仅最后一页盖章

    "ImageUrl" : "https://xxxxxxxx",//图片素材的下载链接

    "FileName" : "sign.png",//图片素材文件名称

    "ScalePercent" : 20,//图片缩放百分比，100 表示不缩放

    "Opacity" : 0.6,//图片透明度，1 表示不透明

    "LocationX" : "(input.Width/10)*6",//图片素材的绝对位置表达式，(0,0) 表示左下角

    "LocationY" : "input.Height/23 +20",//input.With 和 input.Height 代表 pdf 文件的宽度及高度

    "Rotation" : 0//素材的旋转角度

  },

  {

    "SignType" : "text",

    "LastPage" : true,

    "LocationX" : "(input.Width/10)*6+85",

    "LocationY" : "input.Height/23 ",

    "Rotation" : 0,

    "FontSize" : 20,

    "Opacity" : 0.6,

    "FontColor" : {//文本素材的字体颜色值

      "R" : 255,

      "G" : 0,

      "B" : 0

    },

    "Text" : "input.Date"//文本素材的表达式，也可以直接写固定文本

  }

]

说明：

这里之所以设计为一个数组，是因为可能有些场景下，不仅需要盖电子章，还需要自动签上日期，比如本案例。
签署位置可以自定义，坐标(0，0)代表的是左下角，x 变大即表示横向右移，y 变大表示纵向上移。
配置文件存储，我这里是把配置文件放在了本地，当然你可以存储在任何地方，比如 MongoDB等。

代码展示

本案例采用的是 .net7.0，当然 .net6及以后都是可以的。

配置文件类，与上一步的 json 配置文件对应

namespace PdfSign;



public class SignOpt

{

    public string SignType { get; set; }

    public bool LastPage { get; set; }

    public string ImageUrl { get; set; }

    public string FileName { get; set; }

    public int ScalePercent { get; set; } = 50;

    public string LocationX { get; set; }

    public string LocationY { get; set; }

    public float LocationYf { get; set; }

    public float Rotation { get; set; } = 0;

    public int FontSize { get; set; }

    public float Opacity { get; set; }

    public RBGColor FontColor { get; set; }

    public string? Text { get; set; }

    

    public record RBGColor(int R, int G, int B);

}

pdf 签署方法

using System.Dynamic;

using DynamicExpresso;

using iTextSharp.text;

using iTextSharp.text.pdf;

using Newtonsoft.Json.Linq;



namespace PdfSign;



public class SignService

{

    public static string PdfSign(List signOpts, string pdfName)

    {

        var beforeFileName = pdfName; //签名之前文件名

        var afterFileName = pdfName + "_sign"; //签名之后文件名

        var idx = 0;

        foreach (var opt in signOpts)

        {

            //创建盖章后生成pdf

            var outputPdfStream =

                new FileStream(afterFileName + ".pdf", FileMode.Create, FileAccess.Write, FileShare.);

            //读取原有pdf

            var pdfReader = new PdfReader(beforeFileName + ".pdf");

            var pdfStamper = new PdfStamper(pdfReader, outputPdfStream);

            //读取页数

            var pdfPageSize = pdfReader.NumberOfPages;

            //读取pdf文件第一页尺寸，得到 With 和 Height

            var size = pdfReader.GetPageSize(1);

            //通过表达式计算出签署的绝对坐标

            var locationX = Eval(opt.LocationX, new { size.Width, size.Height });

            var locationY = Eval(opt.LocationY, new { size.Width, size.Height });



            if (opt.LastPage)

            {

                //盖章在最后一页

                var pdfContentByte = pdfStamper.GetOverContent(pdfPageSize);

                var gs = new PdfGState

                {

                    FillOpacity = opt.Opacity

                };

                pdfContentByte.SetGState(gs);

                switch (opt.SignType.ToLower())

                {

                    case "image":

                        //获取图片

                        var image = Image.GetInstance(opt.FileName);

                        //设置图片比例

                        image.ScalePercent(opt.ScalePercent);

                        //设置图片的绝对位置,位置偏移方向为：左到右,下到上

                        image.SetAbsolutePosition(locationX, locationY);

                        //图片添加到文档

                        pdfContentByte.AddImage(image);

                        break;

                    case "text":

                        if (string.IsNullOrWhiteSpace(opt.Text))

                            continue;

                        var font = BaseFont.CreateFont();

                        var text = Eval(opt.Text, new { Date = DateTime.Now.ToString("yyyy-MM-dd") });

                        //开始写入文本

                        pdfContentByte.BeginText();

                        pdfContentByte.SetColorFill(

                            new BaseColor(opt.FontColor.R, opt.FontColor.G, opt.FontColor.B));

                        pdfContentByte.SetFontAndSize(font, opt.FontSize);

                        pdfContentByte.SetTextMatrix(0, 0);

                        pdfContentByte.ShowTextAligned(Element.ALIGN_CENTER, text,

                            locationX, locationY, opt.Rotation);



                        pdfContentByte.EndText();

                        break;

                }

            }



            pdfStamper.Close();

            pdfReader.Close();

            idx++;

            if (idx >= signOpts.Count) continue;

            //文件名重新赋值

            beforeFileName = afterFileName;

            afterFileName += "_sign";

        }



        return afterFileName + ".pdf";

    }



    //计算动态表达式的值

    public static T? Eval(string expr, object context)

    {

        if (string.IsNullOrWhiteSpace(expr))

            return default;



        var target = new Interpreter();

        var input = JObject.FromObject(context);



        target.SetVariable("input", input.ToObject());

        return target.Eval(expr);

    }

}

测试调用

using Newtonsoft.Json;

using PdfSign;



//读取签名所需配置文件

var signOpts = await GetSignOpt();



if (signOpts != null && signOpts.Any())

{

    //执行 pdf 文件盖章

    var signFileName= SignService.PdfSign(signOpts, "test");

}



//读取配置文件

static async Task<List<SignOpt>?> GetSignOpt()

{

    var strSign = await File.ReadAllTextAsync("cfg.json");

    return JsonConvert.DeserializeObject<List<SignOpt>>(strSign);

}

效果展示
原 pdf 文件如下图：最终效果如下图：

结束语

随着本文的深入探讨，我们共同经历了一个完整的旅程，从理解电子印章的重要性到实现一个自动化的.NET程序，用于在PDF文件上高效、准确地加盖电子章。我们不仅学习了.NET环境下处理PDF文件的技术细节，还掌握了如何将电子印章整合到我们的应用程序中，以实现自动化的文档认证过程。

作者：架构师小任
来源：juejin.cn/post/7377643248187080715

收起阅读 »

【已解决】uniapp小程序体积过大、隐私协议的问题

web

概述在前几天的工作中又遇到了一个微信小程序上传代码过大的情况，在这里总结一下具体的解决步骤，说明我们需要进一步的优化它，技术栈是使用uniapp框架+HBuilderX的开发环境，微信小程序更新了隐私协议，Http返回信息{errMsg: "getUserP...

继续阅读 »

概述

在前几天的工作中又遇到了一个微信小程序上传代码过大的情况，在这里总结一下具体的解决步骤，说明我们需要进一步的优化它，技术栈是使用uniapp框架+HBuilderX的开发环境，微信小程序更新了隐私协议，Http返回信息{errMsg: "getUserProfile:fail can only be invoked by user TAP gesture."}

定位原因

程序出现问题，首先需要把原因定位归结在第一点，这是解决问题的关键，检查了一下Git仓库的修改情况，发现引入了一个7kb大小的防抖插件，其实7kb的插件不是根本问题，问题是之前的代码写的太不规范了。

压缩资源

尽量把static下面的图片都压缩一下，这里推荐一个好用的压缩网站，图片进行压缩：tinypng.com/

我没有压缩过Js文件，但会有一种方法压缩js文件，使js文件尽量的缩小来减少js文件建立的文件体积。

uniapp官方压缩建议：

小程序工具提示vendor.js过大，已经跳过es6向es5转换。这个转换问题本身不用理会，因为vendor.js已经是es5的了。

关于体积控制，参考如下：

使用运行时代码压缩
HBuilderX创建的项目勾选运行-->运行到小程序模拟器-->运行时是否压缩代码

cli创建的项目可以在package.json中添加参数--minimize，示例："dev:mp-weixin": "cross-env NODE_ENV=development UNI_PLATFORM=mp-weixin vue-cli-service uni-build --watch --minimize"

小程序分包处理

在对应平台的配置下添加 "optimization":{"subPackages":true}开启分包优化

目前只支持 mp-weixin、mp-qq、mp-baidu、mp-toutiao、mp-kuaishou的分包优化

分包优化具体逻辑：

静态文件：分包下支持 static 等静态资源拷贝，即分包目录内放置的静态资源不会被打包到主包中，也不可在主包中使用

js文件：当某个 js 仅被一个分包引用时，该 js 会被打包到该分包内，否则仍打到主包（即被主包引用，或被超过 1 个分包引用）

自定义组件：若某个自定义组件仅被一个分包引用时，且未放入到分包内，编译时会输出提示信息

分包内静态文件示例

"subPackages": [{

	"root": "pages/sub",

	"pages": [{

		"path": "index/index"

	}]

}]

网络请求

还有一个解决小程序体积过大的问题，把非必要的组件都使用Http Api接口的形式去进行交互，尽量去减少本地包中的体积，再根目录下/utils里有一个232kb的获取地址交互，可以替换成Http Api的形式来解决。

隐私协议

在开发微信小程序过程中遇到了{errMsg: "getUserProfile:fail can only be invoked by user TAP gesture."},出现这个信息的原因是微信平台更新了隐私协议，需要再后台备案更新一下,搜索了很多，都不准确，这个隐私协议没有什么特殊情况，2个小时就可以通过了。

设置路径1: 公众号平台->设置->服务内容声明,设置通过后显示的状态是已更新，状态之前的是审核中

设置路径2: 首页->管理->版本管理->提交审核 ，再这里面提审，隐私协议审核过了，就可以继续开发了。

作者：stark张宇
来源：juejin.cn/post/7296025902911897627

收起阅读 »

uniapp微信小程序授权后得到“微信用户”

web

背景近日在开发微信小程序的时候，发现数据库多了很多用户名称是"微信用户"的账号信息。接口的响应信息如下。 (nickName=微信用户, avatarUrl=https://thirdwx.qlogo.cn/mmopen/vi_32/POgEwh4mIHO4...

继续阅读 »

背景

近日在开发微信小程序的时候，发现数据库多了很多用户名称是"微信用户"的账号信息。接口的响应信息如下。

(nickName=微信用户, avatarUrl=https://thirdwx.qlogo.cn/mmopen/vi_32/POgEwh4mIHO4nibH0KlMECNjjGxQUq24ZEaGT4poC6icRiccVGKSyXwibcPq4BWmiaIGuG1icwxaQX6grC9VemZoJ8rg/132, gender=0, country=, province=, city=, language=), code=0e1abNFa1dBwRG0lnoJa18qT0i2abNFk)

经过排查，发现官方是对微信授权的接口做出了调整。小程序用户头像昵称获取规则调整公告

根据上面标红的字体说明，官方的意图就是只提供openid和unionid, 不暴露用户头像昵称数据。

基于此才会在新版的接口中返回"微信用户"的信息。

针对这个问题，官方提供的解决方案如下。

以上解决方案，表达的意思是新版用户授权的接口中，官方只会给你提供unionid和openid.

至于用户的昵称和头像,开发者可以提供功能，以用户的意志去完成修改和更新。

tips: 建议授权接口生成用户名和昵称，采用系统默认的方式。

微信授权流程

uniapp代码实现

uni.login接口文档

后端代码

以上是uniapp和springboot部分代码截图展示，关注微信公众号:JeecgFlow,或微信扫描下面二维码.

回复"微信用户"可以获取完整代码。

异常分析

//如果你的接口出现如下信信息，该如何处理呢？

# {errMsg: “getUserProfile:fail api scope is not

declared in the privacy agreement“, errno: 112}

出现问题的原因: api 范围未在隐私协议中声明,建议大家更具公告，更新对应的隐私协议。

【设置-服务内容声明-用户隐私保护指引】，更新隐私协议，在第一条：开发者处理的信息中，点击【增加信息类型】，选择需要授权的信息，头像昵称我已经勾选了，所以列表中不显示了，根据需求选择和填写其他内容，最后确定并生成协议。等待隐私协议审核通过。

建议按需添加，以防审核不通过。

为了分辨用户，开发者将在获取你的明示同意后，收集你的微信昵称、头像。

为了显示距离，开发者将在获取你的明示同意后，收集你的位置信息。

开发者收集你的地址，用于获取位置信息。

开发者收集你的发票信息，用于维护消费功能。

为了用户互动，开发者将在获取你的明示同意后，收集你的微信运动步数。

为了通过语音与其他用户交流互动，开发者将在获取你的明示同意后，访问你的麦克风。

开发者收集你选中的照片或视频信息，用于提前上传减少上传时间。

为了上传图片或者视频，开发者将在获取你的明示同意后，访问你的摄像头。

为了登录或者注册，开发者将在获取你的明示同意后，收集你的手机号。

开发者使用你的通讯录（仅写入）权限，用于方便用户联系信息。

开发者收集你的设备信息，用于保障你正常使用网络服务。

开发者收集你的身-份-证号码，用于实名认证后才能继续使用的相关网络服务。

开发者收集你的订单信息，用于方便获取订单信息。

开发者收集你的发布内容，用于用户互动。

开发者收集你的所关注账号，用于用户互动。

开发者收集你的操作日志，用于运营维护。

为了保存图片或者上传图片，开发者将在获取你的明示同意后，使用你的相册（仅写入）权限。

为了用户互动，开发者将在获取你的明示同意后，收集你的车牌号。

开发者访问你的蓝牙，用于设备连接。

开发者使用你的日历（仅写入）权限，用于用户日历日程提醒。

开发者收集你的邮箱，用于在必要时和用户联系。

开发者收集你选中的文件，用于提前上传减少上传时间。

当你选择所需的接口后，需要您填写使用说明。可以参考上面的内容进行填写。

给大家看一下我申请的接口。折腾半天终于把授权登录给整好了。

做完上述隐私设置后，需要你重新发布自己的小程序。并且设置成采集用户隐私。

审核通过后就可以啦。如下图，请一定注意！！！

参考文档

头像昵称填写-微信官方文档

 uniapp头像昵称填写

 getUserProfile:fail api scope is not declared in the privacy agreement

作者：代码次位面
来源：juejin.cn/post/7332113324651610150

收起阅读 »

UniApp TabBar的巅峰之作：个性化导航的魅力

web

前言在当今数字化时代，用户界面(UI)设计扮演着至关重要的角色，它不仅仅是产品的外表，更是用户与产品互动的第一印象。在一个社交群里，我有幸结识了一位创业的大佬，陈总，他自研的产品UI设计堪称一流，尤其是引人注目的菜单栏设计，深深吸引了我的注意,我就想着将从零玩...

继续阅读 »

前言

在当今数字化时代，用户界面(UI)设计扮演着至关重要的角色，它不仅仅是产品的外表，更是用户与产品互动的第一印象。在一个社交群里，我有幸结识了一位创业的大佬，陈总，他自研的产品UI设计堪称一流，尤其是引人注目的菜单栏设计，深深吸引了我的注意,我就想着将从零玩转系列之微信支付也优化一下
⚠️注意本次不是从零玩转系列需要有一定的编程能力的同学

二、介绍

UniApp的TabBar

如果应用是一个多 tab 应用，可以通过 tabBar 配置项指定一级导航栏，以及 tab 切换时显示的对应页。
在 pages.json 中提供 tabBar 配置，不仅仅是为了方便快速开发导航，更重要的是在App和小程序端提升性能。在这两个平台，底层原生引擎在启动时无需等待js引擎初始化，即可直接读取 pages.json 中配置的 tabBar 信息，渲染原生tab。
Tips
当设置 position 为 top 时，将不会显示 icon
tabBar 中的 list 是一个数组，只能配置最少2个、最多5个 tab，tab 按数组的顺序排序。
tabbar 切换第一次加载时可能渲染不及时，可以在每个tabbar页面的onLoad生命周期里先弹出一个等待雪花（hello uni-app使用了此方式）
tabbar 的页面展现过一次后就保留在内存中，再次切换 tabbar 页面，只会触发每个页面的onShow，不会再触发onLoad。
顶部的 tabbar 目前仅微信小程序上支持。需要用到顶部选项卡的话，建议不使用 tabbar 的顶部设置，而是自己做顶部选项卡

三、设计

原本的ui样式,真滴丑不好看......
我改造后的,我滴妈真漂亮pink 猛男粉
设计图如下,懂前端的大佬肯定觉得没什么,虽然但是.....我是后端
可以分析他一个大的div包裹并且设置了边框圆形,里面有多个item元素菜单也设置了边框样式,每个菜单上面点击的时候会有背景颜色,我滴妈很简单啊,这我们在从零玩转系列之微信支付当中讲过呀给一个 `class样式如果当前是谁就给谁通过 vue 的动态样式 so easy to happy !

四、实现思路

删除TabBar配置的菜单栏：首先，需要从原始TabBar配置中移除默认的菜单栏，这将为自定义TabBar腾出空间。
自定义底部菜单栏：接下来，自定义创建一个底部菜单栏，他是一个组件页面每个页面都需要引入
自定义样式：使用CSS或相关样式设置，将自定义菜单栏精确地定位到底部，确保它与屏幕底部对齐，以实现预期的效果。

五、删除TabBar配置

好的我们尝试来删除 TabBar 配置重新编译
可以看到报错了,这个错误就是我们使用的是switchTab进行菜单跳转使用别的肯定可以.但是为什么要用switchTab呢?
需求: 和原先的菜单栏功能一样不能销毁其他的菜单页面
那么我们将配置重新填上,他就不会报错了
⚠️注意: 这里有个问题,我们做的是菜单栏在uniapp当中菜单栏跳转是不会销毁其他页面的他其实是根据 switchTab 来进行路由的跳转不回销毁其他TabBar页面
菜单栏跳转的我们是不能销毁的那么这个配置就必须存在了呀,存在就存在无所谓!
遇事不要慌打开文档看看
这个时候我看到了什么? `hide` 隐藏啊给我猜到了.绝壁有!!!!

uni.hideTabBar(OBJECT)

好我们知道有这个懂就行,后面我们进行创建我们的自定义菜单栏组件 `tabbar.vue`

六、自定义TabBar

创建组件 tabbar.vue 这里我们使用vue3组合式Api搭建页面

<template>

  

  <view class="tab-bar">

    

    <view v-for="(item,index) in tabBarList" :key="index"

          :class="{'tab-bar-item': true,currentTar: selected == item.id}"

          @click="switchTab(item, index)">

      <view class="tab_text" :style="{color: selected == index ? selectedColor : color}">

        <image class="tab_img" :src="selected == index ? item.selectedIconPath : item.iconPath">image>

        <view>{{ item.text }}view>

      view>

    view>

  view>

template>

代码详细介绍

: 这是一个外部的 view 元素，它用来包裹整个选项卡栏。

: 这是一个 Vue.js 的循环指令 v-for，它用来遍历一个名为 tabBarList 的数据数组，并为数组中的每个元素执行一次循环。在循环过程中，item 是数组中的当前元素，index 是当前元素的索引。v-for 指令还使用 :key="index" 来确保每个循环元素都有一个唯一的标识符。

:tab-bar-item': true,currentTar: selected == item.id}": 这是一个动态的 class 绑定，它根据条件为当前循环的选项卡元素添加不同的 CSS 类。如果 selected 的值等于当前循环元素的 item.id，则添加 currentTar 类，否则添加 tab-bar-item 类。

@click="switchTab(item, index)": 这是一个点击事件绑定，当用户点击选项卡时，会触发名为 switchTab 的方法，并将当前选项卡的 item 对象和索引 index 作为参数传递给该方法。

: 这是一个包含文本内容的 view 元素，它用来显示选项卡的文本。它还具有一个动态的样式绑定，根据条件选择文本的颜色。如果 selected 的值等于当前循环元素的 index，则使用 selectedColor，否则使用 color。

: 这是一个 image 元素，它用来显示选项卡的图标。它的 src 属性也是根据条件动态绑定，根据 selected 的值来选择显示不同的图标路径。

{{ item.text }}: 这是一个用来显示选项卡文本内容的 view 元素，它显示了当前选项卡的文本，文本内容来自于 item.text。

编写函数

代码当中的 tabBarList 函数要和 pages.json -> tabbar 配置一样哦

<script setup>

import { defineProps, ref } from 'vue'



// 子组件传递参数

const props = defineProps({

  selected: {

    type: Number,

    default: 0

  }

})



// 为选中颜色

let color = ref('#000')

// 选中的颜色

let selectedColor = ref('#ffb2b2')

// 菜单栏集合 - 与 pages.json -> tabbar 配置一样

let tabBarList = ref([

  {

    "id": 0,

    "pagePath": "/pages/index/index",

    "iconPath": "../../static/icon/icon_2.png",

    "selectedIconPath": "../../static/icon/icon_2.png",

    "text": "购买课程"

  },

  {

    "id": 1,

    "pagePath": "/pages/order/order",

    "iconPath": "../../static/icon/gm_1.png",

    "selectedIconPath": "../../static/icon/gm_1.png",

    "text": "我的订单"

  },

  {

    "id": 2,

    "pagePath": "/pages/about/about",

    "iconPath": "../../static/icon/about_3.png",

    "selectedIconPath": "../../static/icon/about_3.png",

    "text": "关于"

  }

])



// 跳转tabBar菜单栏

const switchTab = (item) => {

  let url = item.pagePath;

  uni.switchTab({

    url

  })

}



script>

自定义TabBar样式



<style lang="less" scoped>

// 外部装修

.tab-bar {

  position: fixed;

  bottom: 25rpx;

  left: 15rpx;

  right: 15rpx;

  height: 100rpx;

  background: white;

  padding: 20rpx;

  border-radius: 30rpx;

  display: flex;

  justify-content: center;

  align-items: center;

  box-shadow: 0 4px 15px rgba(165, 168, 171, 0.83) !important;



  // 当前点击的

  .currentTar {

    border-radius: 15rpx;

    box-shadow: 0 0 15px #D7D7D7FF !important;

    transition: all 0.5s ease-in-out;

  }



  // 给每个 item 设置样式

  .tab-bar-item {

    //flex: 0.5;

    text-align: center;

    display: flex;

    justify-content: center;

    align-items: center;

    flex-direction: column;

    width: 150rpx;

    padding: 15rpx;

    background-color: transparent;

    transition: all 0.5s ease-in-out;

    margin: auto;



    // 限制每个icon的大小

    .tab_img {

      width: 37rpx;

      height: 41rpx;

    }



    // 限制文字大小

    .tab_text {

      font-size: 20rpx;

      margin-top: 9rpx;

      flex: 1;

    }

  }

}

style>

测试

我们自定义的效果出来了但是下面是什么鬼.....

可以看到我们下面也有一个菜单栏是 tabbar 配置产生出来的,我们前面不是说了隐藏吗?

修改函数新增隐藏tabbar代码

// 隐藏原生TabBar

uni.hideTabBar();

最后

本期结束咱们下次再见👋~
🌊 关注我不迷路，如果本篇文章对你有所帮助，或者你有什么疑问，欢迎在评论区留言，我一般看到都会回复的。大家点赞支持一下哟~ 💗

作者：杨不易呀
来源：juejin.cn/post/7330295657167290403

收起阅读 »

优雅解决uniapp微信小程序右上角胶囊菜单覆盖问题

跨平台

前言大家好，今天聊一下在做uniapp多端适配项目，需要用到自定义导航时，如何解决状态栏塌陷及导航栏安全区域多端适配问题，下文只针对H5、APP、微信小程序三端进行适配，通过封装一个通用高阶组件包裹自定义导航栏内容，主要是通过设置padding来使内容始终保...

继续阅读 »

前言

大家好，今天聊一下在做uniapp多端适配项目，需要用到自定义导航时，如何解决状态栏塌陷及导航栏安全区域多端适配问题，下文只针对H5、APP、微信小程序三端进行适配，通过封装一个通用高阶组件包裹自定义导航栏内容，主要是通过设置padding来使内容始终保持在安全区域，达到低耦合，可复用性强的效果。

一、创建NavbarWrapper.vue组件

大致结构如下：





<script>

  export default {

    name: 'NavbarWrapper',

    data() {

      return {

        // 像素单位

        pxUnit: 'px',

        // 默认状态栏高度

        statusBarHeight: 'var(--status-bar-height)',

        // 微信小程序右上角的胶囊菜单宽度

        rightSafeArea: 0

      }

    }

  }

script>



<style scoped>

  .navbar-wrapper {

    /**

     * 元素的宽度和高度包括了内边距（padding）和边框（border），

     * 而不会被它们所占据的空间所影响

     * 子元素继承宽度时,只会继承内容区域的宽度 

    */

    box-sizing: border-box;

  }

style>

目的

主要是动态计算statusBarHeight和rightSafeArea的值。

解决方案

在APP端只需一行css代码即可

.navbar-wrapper {

    padding-top: var(--status-bar-height);

}

下面是关于--status-bar-height变量的介绍：

从上图可以知道--status-bar-height只在APP端是手机实际状态栏高度，在微信小程序是固定的25px，并不是手机实际状态栏高度;

在微信小程序时，除了状态栏高度还需要获取右上角的胶囊菜单所占宽度，保持导航栏在安全区域。

以下使用uni.getWindowInfo()和uni.getMenuButtonBoundingClientRect()来分别获取状态栏高度和胶囊相关信息，api介绍如下图所示：

主要逻辑代码

在NavbarWrapper组件创建时，做相关计算

created() {

  const px = this.pxUnit

  // #ifndef H5

  // 获取窗口信息

  const windowInfo = uni.getWindowInfo()

  this.statusBarHeight = windowInfo.statusBarHeight + px

  // #endif



  // #ifdef MP-WEIXIN

  // 获取胶囊左边界坐标

  const { left } = uni.getMenuButtonBoundingClientRect()

  // 计算胶囊(包括右边距)占据屏幕的总宽度：屏幕宽度-胶囊左边界坐标

  this.rightSafeArea = windowInfo.windowWidth - left + px

  // #endif

}

用法

<NavbarWrapper>

  <view class="header">headerview>

NavbarWrapper>

二、多端效果展示

微信小程序

APP端

H5端

三、源码

NavbarWrapper.vue





<script>

  export default {

    name: 'NavbarWrapper',

    data() {

      return {

        // 像素单位

        pxUnit: 'px',

        // 默认状态栏高度

        statusBarHeight: 'var(--status-bar-height)',

        // 微信小程序右上角的胶囊菜单宽度

        rightSafeArea: 0

      }

    },

    created() {

      const px = this.pxUnit

      // #ifndef H5

      // 获取窗口信息

      const windowInfo = uni.getWindowInfo()

      this.statusBarHeight = windowInfo.statusBarHeight + px

      // #endif

      

      // #ifdef MP-WEIXIN

      // 获取胶囊左边界坐标

      const { left } = uni.getMenuButtonBoundingClientRect()

      // 计算胶囊(包括右边距)占据屏幕的总宽度：屏幕宽度-胶囊左边界坐标

      this.rightSafeArea = windowInfo.windowWidth - left + px

      // #endif

    }

  }

script>



<style scoped>

  .navbar-wrapper {

    /**

     * 元素的宽度和高度包括了内边距（padding）和边框（border），

     * 而不会被它们所占据的空间所影响

     * 子元素继承宽度时,只会继承内容区域的宽度 

    */

    box-sizing: border-box;

    background-color: deeppink;

  }

style>

作者：vilan_微澜
来源：juejin.cn/post/7309361597556719679

收起阅读 »

MySQL的 where 1=1会不会影响性能？看完官方文档就悟了！

综合技术讨论

在日常业务开发中，会通过使用where 1=1来简化动态 SQL语句的拼接，有人说where 1=1会影响性能，也有人说不会，到底会不会影响性能？本文将从 MySQL的官方资料来进行分析。动态拼接 SQL的方法在 Mybatis中，动态拼接 SQL最常用的...

继续阅读 »

在日常业务开发中，会通过使用where 1=1来简化动态 SQL语句的拼接，有人说where 1=1会影响性能，也有人说不会，到底会不会影响性能？本文将从 MySQL的官方资料来进行分析。

动态拼接 SQL的方法

在 Mybatis中，动态拼接 SQL最常用的两种方式：使用 where 1=1 和使用标签。

使用where 1=1

使用过 iBATIS的小伙伴应该都知道：在 iBATIS中没有标签，动态 SQL的处理相对较为原始和复杂，因此使用where 1=1这种写法的用户很大一部分是还在使用 iBATIS 或者是从 iBATIS过度到 Mybatis。

如下示例，通过where 1=1来动态拼接有效的 if语句：

<select id="" parameterType = "">

    SELECT * FROM user 

    WHERE 1=1

    <if test="name != null and name != ''">

        AND name = #{name}

    </if>

    <if test="age != null ">

        AND age = #{age }

    </if>

</select>

使用标签

Mybatis提供了标签，标签只有在至少一个 if条件有值的情况下才去生成 where子句，若 AND或 OR前没有有效语句，where元素会将它们去除，也就是说，如果 Mybatis通过标签动态生成的语句为where AND name = '111'，最终会被优化为where name = '111'。

标签使用示例如下：

<select id="" parameterType = "">

    SELECT * FROM user 

    <where>

        <if test="name != null and name != ''">

           AND name = #{name}

        </if>

        <if test="age != null">

           AND age = #{age}

        </if>

    </where>

</select>

标签是在 MyBatis中引入的，所以，很多一开始就使用 MyBatis的用户对这个标签使用的比较多。

性能影响

where 1=1到底会不会影响性能？我们可以先看一个具体的例子：

说明：示例基于 MySQL 8.0.30

可以使用如下指令查看 MySQL版本：

SELECT VERSION();

场景：基于一张拥有 100多万条数据的user表，根据name进行查询，

查看表结构和表的总数据，如下图：

下面，通过执行两条 SQL查询语句（一条带有 1=1）：

select * from user where name = 'name-96d1b3ce-1a24-4d47-b686-6f9c6940f5f6';

select * from user where 1=1 and name = 'name-f692472e-40de-4053-9498-54b9800e9fb1';

对比两条 SQL执行的结果，可以发现它们消耗的时间几乎相同，因此，看起来where 1=1对整体的性能似乎并不影响。

为了排除一次查询不具有代表性，我们分别对两条 SQL语句查询 100遍，然后计算平均值：

SET PROFILING = 1;

DO SLEEP(0.001); -- 确保每次查询之间有足够时间间隔



SET @count = 0;

WHILE @count < 100 DO

select * from user where name = 'name-96d1b3ce-1a24-4d47-b686-6f9c6940f5f6';

-- or

select * from user where 1=1 and name = 'name-f692472e-40de-4053-9498-54b9800e9fb1';

SET @count = @count + 1;

END WHILE;    



SHOW PROFILES;

两条 SQL分别执行 100次后，最终也发现它们的平均值几乎相同，因此，上述示例似乎证明了 where 1=1 对整体的性能并没有不影响。

为什么没有影响？是不是 MySQL对 1=1进行了优化？

为了证明猜想，我们借助show warnings命令来查看信息，在 MySQL中，show warnings命令用于显示最近执行的 SQL语句产生的警告、错误或通知信息。它可以帮助我们了解语句执行过程中的问题。如下示例：

explain select * from user where 1=1 and name = 'name-f692472e-40de-4053-9498-54b9800e9fb1';

show warnings;

将上述示例的 warnings信息摘出来如下：

/* select#1 */ select `yuanjava`.`user`.`id` AS `id`,

      `yuanjava`.`user`.`name` AS `name`,

      `yuanjava`.`user`.`age` AS `age`,

      `yuanjava`.`user`.`sex` AS `sex`,

      `yuanjava`.`user`.`created_at` AS `created_at` 

from `yuanjava`.`user` 

where (`yuanjava`.`user`.`name` = 'name-f692472e-40de-4053-9498-54b9800e9fb1')

从 warnings信息可以看出：1=1已经被查询优化器优化掉，因此，对整体的性能影响并不大。

那么，有没有 MySQL的官方资料可以佐证 where 1=1确实被优化了？

答案：有！MySQL有一种 Constant-Folding Optimization（常量折叠优化）的功能。

Constant-Folding Optimization

MySQL的优化器具有一项称为 Constant-Folding Optimization（常量折叠优化）的功能，可以从查询中消除重言式表达式。Constant-Folding Optimization 是一种编译器的优化技术，用于优化编译时计算表达式的常量部分，从而减少运行时的计算量，换句话说：Constant-Folding Optimization 是发生在编译期，而不是引擎执行期间。

对于上述表达的"重言式表达式"又是什么呢？

重言式

重言式（Tautology ）又称为永真式，它的汉语拼音为：[Chóng yán shì]，是逻辑学的名词。命题公式中有一类重言式，如果一个公式，对于它的任一解释下其真值都为真，就称为重言式（永真式）。

其实，重言式在计算机领域也具有重要应用，比如"重言式表达式"（Tautological expression），它指的是那些总是为真的表达式或逻辑条件。

在 SQL查询中，重言式表达式是指无论在什么情况下，结果永远为真，它们通常会被优化器识别并优化掉，以提高查询效率。例如，如果 where中包含 1=1 或 A=A 这种重言式表达式，它们就会被优化器移除，因为对查询结果没有实际影响。如下两个示例：

SELECT * from user where 1=1 and name = 'xxx';

-- 被优化成

SELECT * from user where name = 'xxx'；



SELECT id, name, salary * (1 + 0.05 * 2) AS real_salary FROM employees;

-- 优化成(1 + 0.05 * 2 被优化成 1.1)

SELECT id, name, salary * 1.1 AS real_salary FROM employees;

另外，通过下面 MySQL架构示意图可以看出：优化器是属于 MySQL的 Server层，因此，Constant-Folding Optimization功能支持受 MySQL Server的版本影响。

查阅了 MySQL的官方资料，Constant-Folding Optimization 从 MySQL5.7版本开始引入，至于 MySQL5.7以前的版本是否具备这个功能，还有待考证。

如何选择？

where 1=1 和 标签 两种方案，该如何选择？

如果 MySQL Server版本大于等于 5.7，两个随便选，或者根据团队的要求来选；

如果 MySQL Server版本小于 5.7，假如使用的是 MyBatis，建议使用 标签，如果使用的还是比较老的 iBATIS，只能使用where 1=1；

如果 MySQL Server版本小于 5.7，建议升升级

信息补充：2009年5月，iBATIS从 2.0版本开始更名为 MyBatis，标签最早出现在MyBatis 3.2.0版本中

总结

where 1=1和 标签到底会不会影响性能，这个问题在网上已经出现了很多次，今天还是想从官方文档来进行说明。本文通过 MySQL的官方资料，加上百万数据的表进行真实测试，得出下面的结论：

如果 MySQL Server版本大于等于 5.7，两个随便选，或者根据团队的要求来选；

如果 MySQL Server版本小于 5.7，假如使用的是 MyBatis，建议使用 标签，如果使用的还是比较老的 iBATIS，只能使用where 1=1；

最后，遇到问题，建议首先查找官方的一手资料，这样才能帮助自己在一条正确的技术道路上成长！

参考资料

MySQL8.0 Constant-Folding Optimization

MySQL5.7 WHERE Clause Optimization

What’s New in MySQL 5.7

作者：猿java
来源：juejin.cn/post/7374238289107648551

收起阅读 »

代码很少，却很优秀！RocketMQ的NameServer是如何做到的？

Java

今天我们来一起深入分析 RocketMQ的注册中心 NameServer。本文基于 RocketMQ release-5.2.0 首先，我们回顾下 RocketMQ的内核原理鸟瞰图：从上面的鸟瞰图，我们可以看出：Nameserver即和 Broker...

继续阅读 »

今天我们来一起深入分析 RocketMQ的注册中心 NameServer。

本文基于 RocketMQ release-5.2.0

首先，我们回顾下 RocketMQ的内核原理鸟瞰图：

从上面的鸟瞰图，我们可以看出：Nameserver即和 Broker交互，也和 Producer和 Consumer交互，因此，在 RocketMQ中，Nameserver起到了一个纽带性的作用。

接着，我们再看看 NameServer的工程结构，如下图：

整个工程只有 11个类（老版本好像只有不到 10个类），为什么 RocketMQ可以用如此少的代码，设计出如此高性能且轻量的注册中心？

我觉得最核心的有 3点是：

AP设计思想

简单的数据结构

心跳机制

`AP`设计思想

像 ZooKeeper，采用了 Zab (Zookeeper Atomic Broadcast) 这种比较重的协议，必须大多数节点（过半数）可用，才能确保了数据的一致性和高可用，大大增加了网络开销和复杂度。

而 NameServer遵守了 CAP理论中 AP，在一个 NameServer集群中，NameServer节点之间是P2P(Peer to Peer)的对等关系，并且 NameServer之间并没有通信，减少很多不必要的网络开销，即便只剩一个 NameServer节点也能继续工作，足以保证高可用。

数据结构

NameServer维护了一套比较简单的数据结构，内部维护了一个路由表，该路由表包含以下几个核心元数据，对应的源码类RouteInfoManager如下：

public class RouteInfoManager {

    private final static long DEFAULT_BROKER_CHANNEL_EXPIRED_TIME = 1000 * 60 * 2; // broker失效时间 120s

    private final ReadWriteLock lock = new ReentrantReadWriteLock();

    private final Map/* topic */, Map> topicQueueTable;

    private final Map/* brokerName */, BrokerData> brokerAddrTable;

    private final Map/* clusterName */, Set/* brokerName */>> clusterAddrTable;

    private final Map/* brokerAddr */, BrokerLiveInfo> brokerLiveTable;

    private final Map/* brokerAddr */, List/* Filter Server */> filterServerTable;

}

topicQueueTable： Topic消息队列路由信息，消息发送时根据路由表进行负载均衡

brokerAddrTable： Broker基础信息，包括brokerName、所属集群名称、主备Broker地址

clusterAddrTable： Broker集群信息，存储集群中所有Broker名称

brokerLiveTable： Broker状态信息，NameServer每次收到心跳包是会替换该信息

filterServerTable： Broker上的FilterServer列表，用于过滤标签（Tag）或 SQL表达式，以减轻 Consumer的负担，提高消息消费的效率。

TopicRouteData

TopicRouteData是 NameServer中最重要的数据结构之一，它包括了 Topic对应的所有 Broker信息以及每个 Broker上的队列信息，filter服务器列表，其源码如下：

public class TopicRouteData {

    private List queueDatas;

    private List brokerDatas;

    private HashMap> filterServerTable;

    //It could be null or empty

    private Map/*brokerName*/, TopicQueueMappingInfo> topicQueueMappingByBroker;

}

BrokerData

BrokerData包含了 Broker的基本属性，状态，所在集群以及 Broker服务器的 IP地址，其源码如下：

public class BrokerData {

    private String cluster;//所在的集群

    private String brokerName;//所在的brokerName

    private HashMap brokerAddrs;//该broker对应的机器IP列表

    private String zoneName; // 区域名称

}

QueueData

QueueData包含了 BrokerName，readQueue的数量，writeQueue的数量等信息，对应的源码类是QueueData，其源码如下：

public class QueueData {

    private String brokerName;//所在的brokerName

    private int readQueueNums;// 读队列数量

    private int writeQueueNums;// 写队列数量

    private int perm; // 读写权限，参考PermName 类

    private int topicSysFlag; // topic同步标记，参考TopicSysFlag 类

}

元数据举例

为了更好地理解元数据，这里对每一种元数据都给出一个数据实例：

topicQueueTable:{

    "topicA":[

        {

            "brokeName":"broker-a",

            "readQueueNums":4,

            "writeQueueNums":4,

            "perm":6, 

            "topicSyncFlag":0 

        },

        {

            "brokeName":"broker-b",

            "readQueueNums":4,

            "writeQueueNums":4,

            "perm":6, 

            "topicSyncFlag":0

        }

    ],

    "topicB":[]

}

brokeAddrTable:{

    "broker-a":{

        "cluster":"cluster-1",

        "brokerName":"broker-a",

        "brokerAddrs":{

            0:"192.168.0.1:8000",

            1:"192.168.0.2:8000"

        }

    },

    "broker-b":{

        "cluster":"cluster-1",

        "brokerName":"broker-b",

        "brokerAddrs":{

            0:"192.168.0.3:8000",

            1:"192.168.0.4:8000"

        }

    }

}

brokerLiveTable:{

    "192.168.0.1:8000":{

        "lastUpdateTimestamp":1533434434344,//long 的时间戳

        "dataVersion":dataVersionObj, //参考DataVersion类

        "channel":channelObj,// 参考io.netty.channel.Channel

        "haServerAddr":"192.168.0.2:8000"

    },

    "192.168.0.2:8000":{

        "lastUpdateTimestamp":1533434434344,//long 的时间戳

        "dataVersion":dataVersionObj, //参考DataVersion类

        "channel":channelObj,// 参考io.netty.channel.Channel

        "haServerAddr":"192.168.0.1:8000"

    },

    "192.168.0.3:8000":{ },

    "192.168.0.4:8000":{ },

}

clusterAddrTable:{

    "cluster-1":[{"broker-a"},{"broker-b"}],

    "cluster-2":[],

}

filterServerTable:{

    "192.168.0.1:8000":[{"192.168.0.1:7000"}{"192.168.0.1:9000"}],

    "192.168.0.2:8000":[{"192.168.0.2:7000"}{"192.168.0.2:9000"}],

}

心跳机制

心跳机制是 NameServer维护 Broker的路由信息最重要的一个抓手，主要分为接收心跳、处理心跳、心跳超时 3部分：

接收心跳

Broker每 30s会向所有的 NameServer发送心跳包，告诉它们自己还存活着，从而更新自己在 NameServer的状态，整体交互如下图：

处理心跳

NameServer收到心跳包时会更新 brokerLiveTable缓存中 BrokerLiveInfo的 lastUpdateTimeStamp信息，整体交互如下图：

处理逻辑可以参考源码：
org.apache.rocketmq.namesrv.processor.DefaultRequestProcessor#processRequest#brokerHeartbeat:

public RemotingCommand brokerHeartbeat(ChannelHandlerContext ctx,

    RemotingCommand request) throws RemotingCommandException {

    final RemotingCommand response = RemotingCommand.createResponseCommand(null);

    final BrokerHeartbeatRequestHeader requestHeader =

        (BrokerHeartbeatRequestHeader) request.decodeCommandCustomHeader(BrokerHeartbeatRequestHeader.class);



    this.namesrvController.getRouteInfoManager().updateBrokerInfoUpdateTimestamp(requestHeader.getClusterName(), requestHeader.getBrokerAddr());



    response.setCode(ResponseCode.SUCCESS);

    response.setRemark(null);

    return response;

}

心跳超时

NameServer每隔 10s(每隔5s + 5s延迟)扫描 brokerLiveTable检查 Broker的状态，如果在 120s内未收到 Broker心跳，则认为 Broker异常，会从路由表将该 Broker摘除并关闭 Socket连接，同时还会更新路由表的其他信息，整体交互如下图：

private void startScheduleService() {

this.scanExecutorService.scheduleAtFixedRate(NamesrvController.this.routeInfoManager::scanNotActiveBroker,

        5, this.namesrvConfig.getScanNotActiveBrokerInterval(), TimeUnit.MILLISECONDS);

}

源码参考：org.apache.rocketmq.namesrv.routeinfo.RouteInfoManager#unRegisterBroker()，核心流程：

遍历brokerAddrTable

遍历broker地址

根据 broker地址移除 brokerAddr

如果当前 Topic只包含待移除的 Broker,则移除该 Topic

其他核心源码解读

NameServer启动

NameServer的启动类为：org.apache.rocketmq.namesrv.NamesrvStartup，整个流程如下图：

图片来自：Mark_Zoe

NameServer启动最核心的 3个事情是：

加载配置：NameServerConfig、NettyServerConfig主要是映射配置文件，并创建 NamesrvController。

启动 Netty通信服务：NettyRemotingServer是 NameServer和Broker，Producer，Consumer通信的底层通道 Netty服务器。

启动定时器和钩子程序：NameServerController实例一方面处理 Netty接收到消息后，一方面内部有多个定时器和钩子程序，它是 NameServer的核心控制器。

总结

NameServer并没有采用复杂的分布式协议来保持数据的一致性，而是采用 CAP理论中的 AP，各个节点之间是Peer to Peer的对等关系，数据的一致性通过心跳机制，定时器，延时感知来完成。

NameServer最核心的 3点设计是：

AP的设计思想

简单的数据结构

心跳机制

作者：猿java
来源：juejin.cn/post/7379431978814275596

收起阅读 »

uni-app新建透明页面实现全局弹窗

web

需求背景实现一个能遮住原生 tabbar 和 navbar 的全局操作框原理使用一个透明的页面来模拟弹窗，这个页面可以遮住原生 tabbar 和 navbar 页面配置 { "path" : "pages/shootAtWill/shootAtW...

继续阅读 »

需求背景

实现一个能遮住原生 tabbar 和 navbar 的全局操作框

原理

使用一个透明的页面来模拟弹窗，这个页面可以遮住原生 tabbar 和 navbar

页面配置

{

    "path" : "pages/shootAtWill/shootAtWill",

    "style" : 

    {

        "navigationBarTitleText" : "随手拍",

        "navigationStyle": "custom",

        "backgroundColor": "transparent",

        "app-plus": {

            "animationType": "slide-in-bottom", // 我这边需求是从底部弹出

            "background": "transparent",

            "popGesture": "none",

            "bounce": "none",

            "titleNView": false,

            "animationDuration": 150

        }

    }

}

页面样式

<style>

	page {

		/* 必须的样式，这是页面背景色为透明色 */

		background: transparent; 

	}

</style>

<style lang="scss" scoped>

  // 写你页面的其他样式

</style>

这样的话就新建成功了一个透明的页面，那么这个页面上的东西都可以遮挡住原生 tabbar 和 navbar

我还加了遮罩：

<template>

  <view>

    <view class="modal" style="z-index: -1"></view>  

    

  </view>

</template>



<style lang="scss" scoped>

   .modal {

      position: fixed;

      top: 0;

      bottom: 0;

      left: 0;

      right: 0;

      background-color: rgba(0, 0, 0, 0.5);

	}

</style>

效果演示

作者：鹏北海
来源：juejin.cn/post/7317325043541639178

收起阅读 »

【干货分享】uniapp做的安卓App如何加固

Android

2023年了，uniapp还有人用吗？对于这个问题，只能说，2023年了，使用uniapp去开发APP的人越来越多了。一方面在于全平台兼容确实很香，对于一些小项目或者时间要求比较高的项目来说，可以节省大量的时间与精力，也为公司节约了成本；另一方面，开发速度...

继续阅读 »

2023年了，uniapp还有人用吗？

对于这个问题，只能说，2023年了，使用uniapp去开发APP的人越来越多了。

一方面在于全平台兼容确实很香，对于一些小项目或者时间要求比较高的项目来说，可以节省大量的时间与精力，也为公司节约了成本；另一方面，开发速度非常快。就像前面说的，对于一些小项目来说，几天就可以搞定，而对于一些大项目来说，性能和原生大差不差，而且全平台兼容的特性也可以弥补这点；最后就是社区，里面有很多优质的框架和插件，节约了大量的时间（时间就是发量！！！），更重要的是，社区出人才，总能找到人和你一起吐槽（bushi）睿智的官方......

总而言之，虽然uniapp文档一般好，bug一般多，更新像拆炸弹，但是，对于很多人来说，还是很有意义的。所以用的人还是很多。

但是目前随着各种商城上架政策的严格审查，对于加固等需求也慢慢起来了，所以今天我们来讲讲uniapp开发的安卓APP要如何加固。

加固原理

先来看看一般加固会从哪几个方向进行加固

而我们如果把uniapp制作的安卓APP在加固上其实大同小异--只要是apk或者aab格式都可以，所以我们就基于这个原理来进行加固。

加固流程

01 代码混淆

按照一般的思路，先给他混淆一下子。使用代码混淆工具来混淆 JavaScript 代码，以使其难以被逆向工程和破解。常用的混淆工具包括 ProGuard 和 DexGuard。在 UniApp 中，你可以在打包安卓应用时配置 ProGuard 来进行代码混淆。示例代码如下所示，在项目根目录下的 uniapp.pro 文件中添加以下配置：

-keep class com.dcloud.** { *; }

-keep public class * extends io.dcloud.* {

    *;

}

02 加固资源文件 & 防止调试和反调试

加固资源文件： 将敏感资源文件（如证书、配置文件等）进行加密或混淆，以防止被攻击者获取。可以使用第三方工具对资源文件进行加密，或者自定义加密算法来保护资源文件的安全

防止调试和反调试： 这一步可以使用第三方库或自定义代码来实现这些保护措施。比如说，可以检测应用程序是否在调试模式下运行，并在调试模式下采取相应的措施，例如关闭应用程序或隐藏敏感信息。

import android.os.Debug;



public class DebugUtils {

    public static boolean isDebugMode() {

        return Debug.isDebuggerConnected();

    }

}

就是说，在应用程序中调用 DebugUtils.isDebugMode() 方法，可以根据返回值来判断应用程序是否在调试模式下运行，并采取相应的措施。

03 加密敏感数据

我们直接使用PBEWithMD5AndDES 算法对数据进行加密和解密。使用的时候，你可以调用 EncryptionUtils.encrypt(data) 方法来加密敏感数据，并调用 EncryptionUtils.decrypt(encryptedData) 方法来解密数据。记得将 PASSWORD 和 SALT 替换为你自己的密码和盐值（重要！！！）。

import javax.crypto.Cipher;

import javax.crypto.SecretKey;

import javax.crypto.SecretKeyFactory;

import javax.crypto.spec.PBEKeySpec;

import javax.crypto.spec.PBEParameterSpec;

import java.security.spec.KeySpec;

import java.util.Base64;



public class EncryptionUtils {

    private static final String ALGORITHM = "PBEWithMD5AndDES";

    private static final String PASSWORD = "your_secret_password"; // 自定义密码，请更换为自己的密码

    private static final byte[] SALT = {

        (byte) 0x4b, (byte) 0x6d, (byte) 0x7d, (byte) 0x15,

        (byte) 0x78, (byte) 0x56, (byte) 0x34, (byte) 0x22

    }; // 自定义盐值，请更换为自己的盐值



    public static String encrypt(String data) {

        try {

            KeySpec keySpec = new PBEKeySpec(PASSWORD.toCharArray(), SALT, 65536);

            SecretKey secretKey = SecretKeyFactory.getInstance(ALGORITHM).generateSecret(keySpec);

            Cipher cipher = Cipher.getInstance(ALGORITHM);

            PBEParameterSpec parameterSpec = new PBEParameterSpec(SALT, 100);

            cipher.init(Cipher.ENCRYPT_MODE, secretKey, parameterSpec);

            byte[] encryptedBytes = cipher.doFinal(data.getBytes("UTF-8"));

            return Base64.getEncoder().encodeToString(encryptedBytes);

        } catch (Exception e) {

            e.printStackTrace();

        }

        return null;

    }



    public static String decrypt(String encryptedData) {

        try {

            KeySpec keySpec = new PBEKeySpec(PASSWORD.toCharArray(), SALT, 65536);

            SecretKey secretKey = SecretKeyFactory.getInstance(ALGORITHM).generateSecret(keySpec);

            Cipher cipher = Cipher.getInstance(ALGORITHM);

            PBEParameterSpec parameterSpec = new PBEParameterSpec(SALT, 100);

            cipher.init(Cipher.DECRYPT_MODE, secretKey, parameterSpec);

            byte[] decodedBytes = Base64.getDecoder().decode(encryptedData);

            byte[] decryptedBytes = cipher.doFinal(decodedBytes);

            return new String(decryptedBytes, "UTF-8");

        } catch (Exception e) {

            e.printStackTrace();

        }

        return null;

    }

}

04 防止篡改

我们使用 SHA-256 哈希算法计算数据的哈希值。使用的时候，可以调用 IntegrityUtils.calculateHash(data) 方法来计算数据的哈希值，并将其与原始的哈希值进行比较，以验证数据的完整性。例如：

String data = "Hello, world!";

String originalHash = "2ef7bde608ce5404e97d5f042f95f89f1c232871";

String calculatedHash = IntegrityUtils.calculateHash(data);



boolean isIntegrityVerified = IntegrityUtils.verifyIntegrity(data, originalHash);

if (isIntegrityVerified) {

    System.out.println("Data integrity verified.");

} else {

    System.out.println("Data has been tampered with!");

}

05 签名功能

补充一个Android签名。

1）简介

本工具用于对android加固后的apk进行重新签名。

版本	文件	备注
Windows版	apk签名工具压缩包.exe	该版本包含Java运行环境，不需要额外安装。
通用版	dx-signer-v1.9r.jar	该版本需要Java 8+的运行环境，请依照操作系统进行安装：Adoptium。

本工具依照Apache 2.0 协议开源，可以在这里查看源码github.com/dingxiangte…。

使用说明

下载签名工具dx-signer.jar，双击运行。

选择输入apk、aab文件。

选择签名的key文件，并输入key密码。

选择重签后apk、aab的路径，以apk结束。如：D:\sign.apk

点击“签名”按钮，等待即可签名完成。

ps:如果有alias（证书别名）密钥的或者有多个证书的，请在高级tab中选择alias并输入alias密码

2）多渠道功能简介

多渠道工具兼容友盟和美团walle风格的多渠道包，方便客户把APP发布到不同的应用平台，进行渠道统计。

使用说明

在app中预留读取渠道信息的入口，具体见5.2.2读取渠道信息

在5.1.1的签名使用基础上，点击选择渠道清单

选择清单文件channel.txt。具体文件格式见5.2.3

点击签名，等待生成多个带签名的渠道app

读取渠道信息

顶象多渠道工具兼容友盟和美团walle风格的多渠道包,下面是两种不同风格的渠道信息读取方法。选其中之一即可

读取渠道信息：UMENG_CHANNEL

输出的Apk中将会包含UMENG_CHANNEL的mata-data



    name="UMENG_CHANNEL"

        android:value="XXX" />

可以读取这个字段。

public static String getChannel(Context ctx) {

    String channel = "";

    try {

        ApplicationInfo appInfo = ctx.getPackageManager().getApplicationInfo(ctx.getPackageName(),

                PackageManager.GET_META_DATA);

        channel = appInfo.metaData.getString("UMENG_CHANNEL");

    } catch (PackageManager.NameNotFoundException ignore) {

    }

    return channel;

}

读取渠道信息：Walle

输出的Apk也包含Walle风格的渠道信息

可以在使用Walle的方式进行读取。

implementation 'com.meituan.android.walle:library:1.1.7'



String channel = WalleChannelReader.getChannel(this.getApplicationContext());

渠道文件格式说明

请准备渠道清单文件channel.txt，格式为每一行一个渠道，例如：

0001_my

0003_baidu

0004_huawei

0005_oppo

0006_vivo

结语

以上就是基于uniapp制作的Android APP的加固方式，仅供参考~ 欢迎一起交流学习~

作者：昀和
来源：juejin.cn/post/7256615625882615866

收起阅读 »

集帅(美)们，别再写 :key = "index" 啦！

web

浅聊一下灵魂拷问：你有没有在v-for里使用过:key = "index"，如果有，我希望你马上改正过来并且给我点个赞，如果没有，来都来了，顺手给我点个赞... 假如您也和我一样，在准备春招。欢迎加我微信shunwuyu，这里有几十位一心去大厂的友友可以相...

继续阅读 »

浅聊一下

灵魂拷问：你有没有在v-for里使用过:key = "index"，如果有，我希望你马上改正过来并且给我点个赞，如果没有，来都来了，顺手给我点个赞...

假如您也和我一样，在准备春招。欢迎加我微信shunwuyu，这里有几十位一心去大厂的友友可以相互鼓励，分享信息，模拟面试，共读源码，齐刷算法，手撕面经。来吧，友友们！

开始

在向掘友们解释为什么不能使用 :key = "index" 之前，我想我还得向你们铺垫一点东西

虚拟DOM

什么是虚拟DOM呢？虚拟DOM是一个对象，没想到吧...我们来看看Vue是如何将template模板里面的东西交给浏览器来渲染的

首先通过 compiler 将 template模板变成一个虚拟DOM，再将虚拟DOM转换成HTML，最后再交给浏览器V8引擎渲染，那么虚拟DOM是什么样的呢？

<!DOCTYPE html>

<html lang="en">



<head>

    <meta charset="UTF-8">

    <meta name="viewport" content="width=device-width, initial-scale=1.0">

    <title>Document</title>

    <script src="https://unpkg.com/vue@3/dist/vue.global.js"></script>

</head>



<body>

    <div id="app">

       <ul id="item">

           <li v-for="item in list" class="item">{{item}}</li>

       </ul>

    </div>

    <script>

        const { createApp, ref } = Vue

        createApp({

            setup() {

               const list = ref(['vue','js','html'])

               return {

                    list

                }

            }

        }).mount('#app')

    </script>

</body>



</html>

在这里，template模板实际上是

 <ul>

      <li v-for="item in list">{{item}}</li>

 </ul>

通过v-for循环，渲染出来了3个li

<ul>

    <li>vue<li>

    <li>js<li>

    <li>html<li>

</ul>

我们的compiler会将这个模板转化成虚拟DOM

let oldDom = {

    tagName = 'ul',

    props:{

        //存放id 和 class 等

        id:'item'

    },

    children[

        {

            tagName = 'li',

            props:{

                class:'item'

            },

            children:['vue']

        },

                {

            tagName = 'li',

            props:{

                class:'item'

            },

            children:['js']

        },

                {

            tagName = 'li',

            props:{

                class:'item'

            },

            children:['html']

        },

    ]

}

diff算法

给前面的例子来点刺激的，加上一个按钮和反转函数，点击按钮，list反转

<!DOCTYPE html>

<html lang="en">



<head>

    <meta charset="UTF-8">

    <meta name="viewport" content="width=device-width, initial-scale=1.0">

    <title>Document</title>

    <script src="https://unpkg.com/vue@3/dist/vue.global.js"></script>

</head>



<body>

    <div id="app">

       <ul>

           <li v-for="item in list">{{item}}</li>

       </ul>

       <button @click="change">change</button>

    </div>

    <script>

        const { createApp, ref } = Vue

        createApp({

            setup() {

               const list = ref(['唱','跳','rap','篮球'])

               const change = ()=>{

                list.value.reverse()

               }

               const add = ()=>{

                list.value.unshift('6')

               }

               return {

                    list,

                    change,

                }

            }

        }).mount('#app')

    </script>

</body>



</html>

点击change按钮，此时我们的DOM更改vue又是如何来更新DOM的呢？

众所周知，回流和重绘会消耗极大的性能，而当DOM发生变更的时候会触发回流重绘(可以去看我的文章(从输入4399.com到页面渲染之间的回流和重绘)，那么vue3就有一个diff算法，用来优化性能

当DOM更改，compiler会生成一个新的虚拟DOM，然后通过diff算法来生成一个补丁包，用来记录旧DOM和新DOM的差异，然后再拿到html里面进行修改，最后再交给浏览器V8进行渲染

简单介绍一下diff算法的比较规则

同层比较，是不是相同的结点，不相同直接废弃老DOM

是相同结点，比较结点上的属性，产生一个补丁包

继续比较下一层的子节点，采用双端对列的方式，尽量复用，产生一个补丁包

同上

别再写 :key = "index"

要说别写 :key = "index" ，我们得先明白key是用来干什么的...如果没有key，那么在diff算法对新旧虚拟DOM进行比较的时候就没法比较了，你看这里有两个一样的vue，当反转顺序以后diff算法不知道哪个vue该对应哪个vue了

如果我们用index来充当key的话来看，当我们在头部再插入一个结点的时候，后面的index其实是改变了的，导致diff算法在比较的时候认为他们与原虚拟DM都不相同，那么diff算法就等于没有用...

可以用随机数吗？

<li v-for="item in list" :key="Math.random()">

想出这种办法的，也是一个狠人...当然是不行的，因为在template模板更新时，会产生一个新的虚拟DOM，而这个虚拟DOM里面的key也是随机值，和原虚拟DOM里的key99.99999%是不一样的...

结尾

希望你以后再也不会写 :key = "index" 了

假如您也和我一样，在准备春招。欢迎加我微信shunwuyu，这里有几十位一心去大厂的友友可以相互鼓励，分享信息，模拟面试，共读源码，齐刷算法，手撕面经。来吧，友友们！

作者：滚去睡觉
来源：juejin.cn/post/7337513012394115111

收起阅读 »

VSCode无限画布模式（可能会惊艳到你的一个小功能）

综合技术讨论

❓现存的痛点VSCode是我的主力开发工具，在实际的开发中，我经常会对编辑器进行分栏处理，组件A的tsx、css代码、工具类方法各一个窗口，组件B的tsx、css代码、工具类方法各一个窗口，组件C的......当组件拆的足够多的时候，多个分栏会把本就不大的编辑...

继续阅读 »

❓现存的痛点

VSCode是我的主力开发工具，在实际的开发中，我经常会对编辑器进行分栏处理，组件A的tsx、css代码、工具类方法各一个窗口，组件B的tsx、css代码、工具类方法各一个窗口，组件C的......

当组件拆的足够多的时候，多个分栏会把本就不大的编辑器窗口分成N份，每一份的可视区域就小的可怜，切换组件代码时，需要不小的翻找成本，而且经常忘记我之前把文件放在了那个格子里，特别是下面的场景（一个小窗口内开了N个小tab），此时更难找到想要的窗口了...

问题汇总

分栏会导致每个窗口的面积变小，开发体验差（即使可以双击放大，但效果仍不符合预期）；
编辑器窗口容易被新打开的窗口替换掉，常找不到之前打开的窗口；
窗口的可操作性不强，位置不容易调整。

💡解题的思路

1. 自由 & 独立的编辑器窗口

~~分栏会导致每个窗口的面积变小，开发体验不好。~~

那就别变小了！每个编辑器窗口都还是原来的大小，甚至更大!

2. 无限画布

~~编辑器窗口容易被新打开的窗口替换掉，常找不到之前打开的窗口。~~
~~窗口的可操作性不强，位置不容易调整。~~

那就每个窗口都拥有一个自己的位置好了！拖一下就可以找到了！

3. 画布体验

好用的画布是可以较大的提升用户体验的，下面重点做了四个方面的优化：

3.1 在编辑器里可以快速缩小 & 移动

因为不可避免的会出现一些事件冲突（比如编辑器里的滚动和画布的滚动、缩放等等），通过提供快捷键的解法，可以在编辑器内快速移动、缩放画布。

command + 鼠标上下滑动 = 缩放
option + 鼠标移动 = 画布移动

注意下图，鼠标还在编辑器窗口中，依然可以拖动画布👇🏻

3.2 快速放大和缩小编辑窗口

通过快捷按钮的方式，可以快速的放大和缩小编辑器窗口。

3.3 一键定位到中心点

不小心把所有窗口都拖到了画布视口外找不到了？没事儿，可以通过点击快捷按钮的方式，快速回到中心点。

3.4 窗口的合并和分解

可以在窗口下进行编辑器的合并，即可以简单的把一些常用的窗口进行合并、分解。

💬 提出的背景

作为一名前端开发同学，避免不了接触UI同学的设计稿，我司使用的就是figma，以figma平台为例，其无限画布模式可以非常方便的平铺N个稿子，并快速的看到所有稿子的全貌、找到自己想要的稿子等等，效果如下：

没错！我就是基于这个思路提出了第一个想法，既然图片可以无限展示，编辑器为什么不能呢？

这个想法其实去年就有了，期间大概断断续续花了半年多左右的时间在调研和阅读VSCode的源码上，年后花了大概3个月的时间进行实现，最终在上个月做到了上面的效果。

经过约一个月的试用（目前我的日常需求均是使用这种模式进行的开发），发现效果超出预期，我经常会在画布中开启约10+个窗口，并频繁的在各个窗口之间来回移动，在这个过程中，我发现以下几点很让我很是欣喜：

空间感：我个人对“空间和方向”比较敏感，恰好画布模式会给我一种真实的空间感，我仿佛在一间房子里，里面摆满了我的代码，我穿梭在代码中，修一修这个，调一调这个~
满足感：无限画布的方式，相当于我间接拥有了无限大的屏幕，我只需要动动手指找到我的编辑窗口就好了，它可以随意的放大和缩小，所以我可以在屏幕上展示足够多的代码。
更方便的看源码：我可以把源码的每个文件单独开一个窗口，然后把每个窗口按顺序铺起来，摆成一条线，这条线就是源码的思路（当然可以用截图的方式看源码 & 缕思路，但是，需要注意一点，这个编辑器是可以交互的！）

⌨️ 后续的计划

后续计划继续增强画布的能力，让它可以更好用：

小窗口支持命名，在缩小画布时，窗口缩小，但是命名不缩小，可以直观的找到想要的窗口。
增强看源码的体验：支持在画布上添加其他元素（文案、箭头、连线），试想一下，以后在看源码时，拥有一个无限的画板来展示代码和思路，关键是代码是可以交互的，这该有多么方便！
类似MacOS的台前调度功能：把有关联的一些窗口分组，画布一侧有分组的入口，点击入口可以切换画布中的组，便于用户快速的进行批量窗口切换，比如A页面的一些JS、CSS等放在一个组，B页面放在另一个组，这样可以快速的切换文件窗口。

📔 其他的补充

调研过程中发现无法使用VSCode的插件功能来实现这个功能，所以只好fork了一份VSCode的开源代码，进行了大量修改，最终需要对源码进行编译打包才能使用（一个新的VSCode），目前只打包了mac的arm64版本来供自己试用。

另外，由于VSCode并不是100%开源（微软的一些服务相关的逻辑是闭源的），所以github上的开源仓库只是它的部分代码，经过编译之后，发现缺失了远程连接相关的功能，其他的功能暂时没有发现缺失。

🦽 可以试用吗

目前还没有对外提供试用版的打算，想自己继续使用一些时间，持续打磨一下细节，等功能细节更完善了再对外进行推广，至于这次的软文~ 其实是希望可以引起阅读到这里的同学进行讨论，可以聊一下你对该功能的一些看法，以及一些其他的好点子~，thx~

🫡 小小的致敬

致敬VSCode团队，在阅读和改造他们代码的过程中学习到了不少hin有用的代码技能，也正是因为有他们的开源，才能有我的这次折腾👍🏻
致敬锤子科技罗永浩老师，这次实现思路也有借鉴当年发布的“无限屏”功能，本文的头图就是来自当年的发布会截图。

作者：木头就是我呀
来源：juejin.cn/post/7375586227984220169

收起阅读 »

安卓高版本HTTPS抓包：终极解决方案

Android

虽然市面上有好多抓包工具，但是 Android 高版本都需要安装抓包工具的证书到系统目录，才能抓 https 协议的包。本文就以 Charles这个抓包工具来介绍，如何安装证书到 Android 的系统目录，实现 https 抓包。修改证书名称启动 Cha...

继续阅读 »

虽然市面上有好多抓包工具，但是 Android 高版本都需要安装抓包工具的证书到系统目录，才能抓 https 协议的包。本文就以 Charles这个抓包工具来介绍，如何安装证书到 Android 的系统目录，实现 https 抓包。

修改证书名称

启动 Charles，通过菜单栏中的 Help → SSL Proxying → Save Charles Root Certificate… 将 Charles 的证书导出。
使用 OpenSSL 查看证书在 Android 系统中对应的文件名，并重命名证书文件

openssl x509 -subject_hash_old -in charles-ssl-proxying-certificate.pem | head -n 1  #cdfb61bc

mv charles-ssl-proxying-certificate.pem cdfb61bc.0

将证书安装到系统证书目录下

使用 adb push 命令将我们的证书文件放到 SD 卡中

adb push cdfb61bc.0 /sdcard/Download

使用 adb 连接手机并切换到 root 用户

adb shell

su

将证书文件移动到 /system/etc/security/cacerts 目录下，由于 /system 默认是只读的，所以要先重新挂载为其添加写入权限

cat /proc/mounts  #查看挂载信息，这里我的 /system 是直接挂载到 / 的



mount -o rw,remount /

mv /sdcard/Download/cdfb61bc.0  /system/etc/security/cacerts

chmod 644 /system/etc/security/cacerts/cdfb61bc.0  #设置文件权限

如果👆的步骤你都能成功，就不用继续往下看了。

终极解决方案

我用我手上的手机都试了一下，用上面的方式安装正式，发现不能成功，一直提示 Read-only file system，但是HttpToolkit这个软件确可以通过 Android Device Via ADB来抓 https 的包。
它是怎么实现的呢？
这下又开始了漫长的谷歌之旅，最后在他们官网找到一篇文章，详细讲述了 通过有root权限的adb 来写入系统证书的神奇方案。

通过 ADB 将 HTTP Toolkit CA 证书推送到设备上。

从 /system/etc/security/cacerts/ 中复制所有系统证书到临时目录。

在 /system/etc/security/cacerts/ 上面挂载一个 tmpfs 内存文件系统。这实际上将一个可写的全新空文件系统放在了 /system 的一小部分上面。将复制的系统证书移回到该挂载点。

将 HTTP Toolkit CA 证书也移动到该挂载点。

更新临时挂载点中所有文件的权限为 644，并将系统文件的 SELinux 标签设置为 system_file，以使其看起来像是合法的 Android 系统文件。

关键点就是挂载一个 内存文件系统， 太有才了。
具体命令如下

# 创建一个独立的临时目录，用于存储当前的证书

# 如果不这样做，在我们添加挂载后将无法再读取到当前的证书。

mkdir -m 700 /data/local/tmp/htk-ca-copy

# 复制现有的证书到临时目录

cp /system/etc/security/cacerts/* /data/local/tmp/htk-ca-copy/

# 在系统证书文件夹之上创建内存挂载点

mount -t tmpfs tmpfs /system/etc/security/cacerts

# 将之前复制的证书移回内存挂载点中，确保继续信任这些证书

mv /data/local/tmp/htk-ca-copy/* /system/etc/security/cacerts/

# 将新的证书复制进去，以便我们也信任该证书

cp /data/local/tmp/c88f7ed0.0 /system/etc/security/cacerts/

# 更新权限和SELinux上下文标签，确保一切都和之前一样可读

chown root:root /system/etc/security/cacerts/*

chmod 644 /system/etc/security/cacerts/*

chcon u:object_r:system_file:s0 /system/etc/security/cacerts/*

# 删除临时证书目录

rm -r /data/local/tmp/htk-ca-copy

注意：由于是内存文件系统，所以重启手机后就失效了。可以将以上命令写成 shell 脚本，需要抓包的时候执行下就可以了。

作者：平行绳
来源：juejin.cn/post/7360242772303577125

收起阅读 »

接口幂等和防抖还在傻傻分不清楚。。。

Java

最近想重温下接口幂等的相关知识，正所谓温故而知新，太久不CV的东西要是哪天CV起来都生疏了，哈哈哈先从字面意思来温习下吧，幂等的官方概念来源于数学上幂等概念的衍生，如幂等函数，即使用相同的参数重复执行，可以得到相同的结果的函数，翻译成IT行业专业术语就是一个...

继续阅读 »

最近想重温下接口幂等的相关知识，正所谓温故而知新，太久不CV的东西要是哪天CV起来都生疏了，哈哈哈

先从字面意思来温习下吧，幂等的官方概念来源于数学上幂等概念的衍生，如幂等函数，即使用相同的参数重复执行，可以得到相同的结果的函数，翻译成IT行业专业术语就是一个接口使用相同的入参，无论执行多少次，最后得到的结果且保存的数据和执行一次是完全一样的，所以，基于这个概念，分析我们的CRUD，首先，查询，它可以说是幂等的，但是如果更精细的说，它也可能不是幂等的，基于数据库数据不变的情况下，查询接口是幂等的，如果是变化的话那可能上一秒你查出来的数据，下一秒它就被人修改了也不是不可能，所以，基于这一点它不符合幂等概念

接下来是删除接口，它和查询一样，也是天然幂等的，但是如果你的接口提供范围删除，那么就破坏了幂等性原则，理论上这个删除接口就不应该存在，那如果是产品经理非要那也是可以存在滴，技术永远都是为业务服务的嘛

修改接口也是同样的道理，理论上都必须是幂等的，如果不是，那就要考虑接口幂等性了，比如你的修改积分接口里写修改积分，每次都使用i++这种操作,那么它就破坏了幂等原则，有一个好方法就是基于用户唯一性标识把积分变动通过一张表记录下来，最后统计这张表的积分数值，这里也就涉及到新增接口的知识点，其实到这里，我们会发现，所有的接口理论上都可以是幂等的，但是总是这个那个的原因导致不幂等，所以，总结起来就是，如果你的系统需求需要接口幂等，那么就实现它，现在让我们进入正题吧

刚开始温习幂等知识的时候，我百度了很多别人写的文章，发现另一个概念，叫防抖，防止用户重复点击的意思，有意思的是有些文章竟然认为防抖就是幂等，他们解决接口幂等的思路是每次调用需要实现幂等接口时，前端都需要调用后端的颁布唯一token的接口，后端颁布token后保存在缓存中，然后前端带着这个token的请求去请求我们的幂等接口，验证携带的token来实现接口幂等，按照这个思路每次请求的token都不一样，如何保证幂等中相同参数的条件呢，这显然和幂等南辕北辙了，这显然就是接口防抖或者接口加锁的思路嘛

还有一种是可以实现接口幂等性的思路，这里也可以分享一下，和上面的思路差不多，也是每次请求幂等接口的时候，先调用颁发唯一token的接口，唯一不同的是它颁发的token是基于入参生成的哈希值，后面的业务逻辑就是后端基于这个哈希值去校验，如果缓存中已经存在了，说明这个入参已经请求过了，那么直接拒绝请求并返回成功，这样，就从表面上实现了接口幂等性，因为执行100次我只执行一次，剩余的99次我都拒绝，并直接返回成功，这样，我的接口就从表面上幂等了，但是这个方案有一个很大的问题就是每次调用都需要浪费一部分资源在请求颁发token上，这对需要大量的幂等接口的系统来说就是一个累赘，所以，接下来，我们基于这个思路实现一个不需要二次调用的实现接口幂等的方法。

我的思路是这样的，业务上有些接口是实现防抖功能，有些是实现幂等功能，其实这两个功能在业务上确实是相差不大，所以，我的思路是定义一个注解，包含防抖和幂等的功能，首先基于幂等如果要是把所有入参都哈希化作为唯一标识的话有点费劲，可以基于业务上的一些唯一标识来做，如用户id或者code，还需要一个开关，用于决定是否保存这个唯一标识，还要一个时间，保存多久，还有保存时间的单位，最后，还有一个返回提醒，就是拒绝之后的友好提示，基于这些差不多了，如果你的接口功能只需要实现防抖，那么你可以设置时间段内过期，这样就实现了防抖，如果你的接口没有唯一标识，那么可以基于路由来做防抖，这个不要忘了设置过期时间，不然你的接口就永远是拒绝了，好了，思路有了，接下来就是实操了，话不多数，上代码

@Retention(RetentionPolicy.RUNTIME)

//注解用于方法

@Target({ElementType.TYPE, ElementType.METHOD})

//注解包含在JavaDoc中

@Documented

public @interface Idempotent {



    /**

     * 幂等操作的唯一标识，使用spring  el表达式  用#来引用方法参数

     *

     * @return Spring-EL  expression

     */

    String key() default "";



    /**

     * 有效期  默认：1  有效期要大于程序执行时间，否则请求还是可能会进来

     *

     * @return expireTime

     */

    int expireTime() default 100;



    /**

     * 时间单位  默认：s

     *

     * @return TimeUnit

     */

    TimeUnit timeUnit() default TimeUnit.SECONDS;



    /**

     * 提示信息，可自定义

     *

     * @return String

     */

    String info() default "重复请求，请稍后重试";



    /**

     * 是否在业务完成后删除key  true:删除  false:不删除

     *

     * @return boolean

     */

    boolean delKey() default false;

基本和我们上面的思路一样，唯一key，有效期，有效期时间单位，提示信息，是否删除，注解有了，那么我们就要基于注解写我们的逻辑了，这里我们需要用到aop，引用注解应该都知道吧，这里我们直接上代码了

@Aspect

@Slf4j

public class IdempotentAspect {

    @Resource

    private RedisUtil redisUtil;



    private static final SpelExpressionParser PARSER = new SpelExpressionParser();



    private static final LocalVariableTableParameterNameDiscoverer DISCOVERER = new LocalVariableTableParameterNameDiscoverer();



    /**

     * 线程私有map

     */

    private static final ThreadLocal<Map<String, Object>> THREAD_CACHE = ThreadLocal.withInitial(HashMap::new);



    private static final String KEY = "key";



    private static final String DEL_KEY = "delKey";



    // 以自定义 @Idempotent 注解为切点

    @Pointcut("@annotation(com.liuhui.demo_core.spring.Idempotent)")

    public void idempotent() {

    }



    @Before("idempotent()")

    public void before(JoinPoint joinPoint) throws Throwable {

        //获取到当前请求的属性，进而得到HttpServletRequest对象，以便后续获取请求URL和参数信息。

        ServletRequestAttributes requestAttributes = (ServletRequestAttributes) RequestContextHolder

                .getRequestAttributes();

        HttpServletRequest request = requestAttributes.getRequest();

        //从JoinPoint中获取方法签名，并确认该方法是否被@Idempotent注解标记。如果是，则继续执行幂等性检查逻辑；如果不是，则直接返回，不进行幂等处理。。

        MethodSignature signature = (MethodSignature) joinPoint.getSignature();

        Method method = signature.getMethod();

        if (!method.isAnnotationPresent(Idempotent.class)) {

            return;

        }

        Idempotent idempotent = method.getAnnotation(Idempotent.class);

        String key;

        // 若没有配置 幂等 标识编号，则使用 url + 参数列表作为区分;如果提供了key规则，则利用keyResolver根据提供的规则和切点信息生成键

        if (!StringUtils.hasLength(idempotent.key())) {

            String url = request.getRequestURL().toString();

            String argString = Arrays.asList(joinPoint.getArgs()).toString();

            key = url + argString;

        } else {

            // 使用jstl 规则区分

            key = resolver(idempotent, joinPoint);

        }

        //从注解中读取并设置幂等操作的过期时间、描述信息、时间单位以及是否删除键的标志。

        long expireTime = idempotent.expireTime();

        String info = idempotent.info();

        TimeUnit timeUnit = idempotent.timeUnit();

        boolean delKey = idempotent.delKey();

        String value = LocalDateTime.now().toString().replace("T", " ");

        Object valueResult = redisUtil.get(key);

        synchronized (this) {

            if (null == valueResult) {

                redisUtil.set(key, value, expireTime, timeUnit);

            } else {

                throw new IdempotentException(info);

            }

        }

        Map<String, Object> map = THREAD_CACHE.get();

        map.put(KEY, key);

        map.put(DEL_KEY, delKey);

    }





    /**

     * 从注解的方法的参数中解析出用于幂等性处理的键值（key）

     *

     * @param idempotent

     * @param point

     * @return

     */

    private String resolver(Idempotent idempotent, JoinPoint point) {

        //获取被拦截方法的所有参数

        Object[] arguments = point.getArgs();

        //从字节码的局部变量表中解析出参数名称

        String[] params = DISCOVERER.getParameterNames(getMethod(point));

        //SpEL表达式执行的上下文环境，用于存放变量

        StandardEvaluationContext context = new StandardEvaluationContext();

        //遍历方法参数名和对应的参数值，将它们一一绑定到StandardEvaluationContext中。

        //这样SpEL表达式就可以引用这些参数值

        if (params != null && params.length > 0) {

            for (int len = 0; len < params.length; len++) {

                context.setVariable(params[len], arguments[len]);

            }

        }

        //使用SpelExpressionParser来解析Idempotent注解中的key属性，将其作为SpEL表达式字符串

        Expression expression = PARSER.parseExpression(idempotent.key());

        //转换结果为String类型返回

        return expression.getValue(context, String.class);

    }



    /**

     * 根据切点解析方法信息

     *

     * @param joinPoint 切点信息

     * @return Method    原信息

     */

    private Method getMethod(JoinPoint joinPoint) {

        //将joinPoint.getSignature()转换为MethodSignature

        //Signature是AOP中表示连接点签名的接口，而MethodSignature是它的具体实现，专门用于表示方法的签名。

        MethodSignature signature = (MethodSignature) joinPoint.getSignature();

        //获取到方法的声明。这将返回代理对象所持有的方法声明。

        Method method = signature.getMethod();



        //判断获取到的方法是否属于一个接口

        //因为在Java中，当通过Spring    AOP或其它代理方式调用接口的方法时，实际被执行的对象是一个代理对象，直接获取到的方法可能来自于接口声明而不是实现类。

        if (method.getDeclaringClass().isInterface()) {

            try {

                //通过反射获取目标对象的实际类（joinPoint.getTarget().getClass()）中同名且参数类型相同的方法

                //这样做是因为代理类可能对方法进行了增强，直接调用实现类的方法可以确保获取到最准确的实现细节

                method = joinPoint.getTarget().getClass().getDeclaredMethod(joinPoint.getSignature().getName(),

                        method.getParameterTypes());

            } catch (SecurityException | NoSuchMethodException e) {

                throw new RuntimeException(e);

            }

        }

        return method;

    }





    @After("idempotent()")

    public void after() throws Throwable {

        Map<String, Object> map = THREAD_CACHE.get();

        if (CollectionUtils.isEmpty(map)) {

            return;

        }



        String key = map.get(KEY).toString();

        boolean delKey = (boolean) map.get(DEL_KEY);

        if (delKey) {

            redisUtil.delete(key);

            log.info("[idempotent]:has removed key={}", key);

        }

        //无论是否移除了键，最后都会清空当前线程局部变量THREAD_CACHE中的数据，避免内存泄漏

        THREAD_CACHE.remove();

    }

 }

上面redisUtil是基于RedisTemplate封装的工具类，可以直接替换哈，这里我们定义一个切入点，也就是我们定义的注解，然后在调用接口之前获取到接口的入参以及注解的参数，获取到这些之后，判断是否有唯一标识，没有就用路由，保存到reids当中，然后设置过期时间，最后需要把删除的标识放到线程私有变量THREAD_CACHE中在接口处理完之后判断是否需要删除redis当中保存的key，这里，我们的逻辑就写完了，接下来是使用了，使用这个就很简单，直接在你需要实现防抖和幂等的接口上打上我们的注解

/**

 * 测试接口添加幂等校验

 *

 * @return

 */

@PostMapping("/redis")

@Idempotent(key = "#user.id", expireTime = 10, delKey = true, info = "重复请求，请稍后再试")

public Result<?> getRedis(@RequestBody User user) throws InterruptedException {

    return Result.success(true);

}

这里key的定义方式我们使用了SpEL表达式，如果不指定这个表达式的话就会使用路由作为key了

到这里，接口幂等和防抖功能就顺利完成了，以后，别再防抖和幂等傻傻分不清楚了哈哈哈

最后，还是要送上一位名人曾说的一句话：手上没有剑和有剑不用是两回事！

作者：失乐园
来源：juejin.cn/post/7380274613185970195

收起阅读 »

探索副业的路上：赚钱的机会往往在你眼前，请不要视而不见

职场话题

前言 Hi 你好，我是东东拿铁，一个正在探索个人IP&副业的后端程序员。对于普通人来说，赚钱的机会往往是那些看不上、瞧不起的信息差。我们的认知，对于看到的项目，可能天生把他归结于大项目、或者小项目。但每一个赚钱机会，是从每一个小的机会，叠加了风口...

继续阅读 »

前言

Hi 你好，我是东东拿铁，一个正在探索个人IP&副业的后端程序员。

对于普通人来说，赚钱的机会往往是那些看不上、瞧不起的信息差。

我们的认知，对于看到的项目，可能天生把他归结于大项目、或者小项目。

但每一个赚钱机会，是从每一个小的机会，叠加了风口、资金、团队、产品等杠杆，叠加成了一个大的赚钱机会。

所以说，赚钱的机会往往是那些我们看不上、瞧不起的信息差。

看不起就会错过

比如说大学期间，我曾经对微商嗤之以鼻。卖假货、朋友圈刷屏，太low了！

几年之后，当年做微商的，做得好的赚到第一桶金，做得不好，也积累了项目经验、私域用户。

工作后，我觉着那些整理面经的，没什么意思，不就是罗列了知识，照着书本上的内容，那可差的太远了，有这时间我看看书不好吗？

但整理面经的，在技术平台持续输出的那些人，不但积累了第一波粉丝，在那个快速发展的时间，很多人靠公众号赚到了第一桶金。

看不上、瞧不起的时候，实际上是封闭了自己。

我现在也在写一些技术文章、面经，恰恰是做了自己曾经看不起的事情了。

其实时至今日，我也会有这样的毛病，互联网从来不缺少赚钱的机会。

身边有通过闲鱼赚了10w+的大佬，也有做AI公众号文章，月入过千的自媒体写手。

即使接触了这些人，我的内心也总会有些怀疑的态度，闲鱼的货源怎么办，时刻需要回复客户信息，消耗经历太大怎么办。AI写文章起号难，输出的内容自己又觉着没价值，没有什么前途怎么办。

怎么做

保持开放

保持头脑开放，让信息流入进来

持有怀疑的心态没问题，凡事有利有弊，再小的项目，也有能赚到大钱的，和赚不到钱的人。

但不能天然的排斥这些信息，很多人对于看到的赚钱信息，内心总会说出一个声音：“赚钱的事情谁会真的分享给你啊，肯定是骗人的”。

你是不也经常会有这样的想法？

其实是的，现在非常流行知识付费，市面上确实存在着通过几个赚钱项目，吸引你来买课学习、割韭菜的课程。

但同样的，一定也有优质的信息，来帮助你打平信息差、快速上手，这时候我们需要提升的是鉴别能力，这个我们有空再聊。

先干起来再说

有了充足的信息、案例，如何去做呢？

找到自己热爱或者擅长的事情。

我这里用了或，而不是且，是我最近刚刚想清楚的一个道理。

每个人都有热爱、擅长的事情，如果有一个赚钱机会，既符合你热爱，也很擅长，那是最好的。但这样的机会可遇不可求。

我到今天都还希望找到一个热爱且擅长的事情，但是我发现好难。

不到半年时间，我写了28篇文章，这是第29篇。我还是蛮喜欢写东西的，既能说说心里话，也能积累写作这个最基础的能力。

但我真的不擅长这件事情，可能在几年内，我都不敢说我自己擅长写作，因为市面上有太多输出能力很强的大佬，有太多写作课程了。

市面上真的缺少我一个内容创作者吗？那你说，我为什么还要去写，还要持续输出呢？

去尝试一下，没什么成本，先干起来再说。

保持专注

俗话说：“师傅领进门，修行在个人。”

保持专注，就是找到一个方向，在这个领域里深耕。没有在一个方向的专注，是很难赚到钱的。

写作方向的大佬，比如粥大，写了上百篇10w+阅读的文章。很多有了自己写作课程的知识型博主，都已经日更公众号几百天、上千天。

每个人的擅长都不是找到的，而是自己努力去做到的。

说在最后

在今天，我也决定列出我今年的目标，完成一百篇原创文章，持续分享我在探索个人IP道路上的思考、经验，欢迎你关注、围观。

作者：东东拿铁
来源：juejin.cn/post/7358639642412122166

收起阅读 »

面试问空窗期，HR到底想听什么？

职场话题

职场中的空窗期，无论是新人还是老手，都可能会遇到，而且因人而异。因此，离职后，建议空窗期不宜过长，万一真的有空窗期，在面试中该如何回答呢？今天我们来聊一聊。空窗期产生的原因职场空窗期产生的原因多种多样，这里总结出主要的 2个因素：个人因素比如，由于工作...

继续阅读 »

职场中的空窗期，无论是新人还是老手，都可能会遇到，而且因人而异。因此，离职后，建议空窗期不宜过长，万一真的有空窗期，在面试中该如何回答呢？今天我们来聊一聊。

空窗期产生的原因

职场空窗期产生的原因多种多样，这里总结出主要的 2个因素：

个人因素

比如，由于工作压力大，想给自己一段时间休息和调整或者薪资待遇不满意等多方面因素，导致冲动“裸辞”；

又比如，很多大学生，在校招期间没有匹配到合适的工作，踏上社会后又眼高手低，导致企业和个人都不满意，也经常会出现空窗期的问题；

再比如，因为家庭原因不得不离开职场一段时间；

外在因素

比如，经济不景气、公司倒闭、行业调整、裁员等无法改变的外在因素，然后无法快速地衔接下一份工作。

HR为什么很关注空窗期？

HR关注空档期，主要有以下几个原因：

担忧求职者稳定性：HR担心求职者流动性强，可能不稳定。长期空窗期可能暗示个人适应能力不足或求职者可能频繁离职。担忧求职者能力匹配度：HR关注求职者是否有能力与岗位匹配，长期空窗期可能暗示了求职者的能力不足，以至于长时间找不到工作。担忧个人生活因素：HR可能担心求职者个人生活琐事过多，影响工作表现。长期空窗期可能反映个人生活稳定性问题。

如何回答空窗期？

求职者在面对空窗期时，应当诚实面对，避免隐瞒或虚假解释。对于空窗期，可用积极的态度和合理的解释来回答面试官的提问，下面根据空窗期的时间长短给出一些建议：

3个月以内

一般三个月以内的空窗期，问题不是特别大，可以先说明离职原因，比如公司组织架构调整，部门全部被优化，借此机会给自己一段时间休息和调整，现在已经调整好状态，可以更好的投入下一份工作，一般这样回答，HR也不会太纠结。

3～6个月

3～6个月时间还是有点长，这里给出给出 2个比较通用的原因：

在先前的工作中感觉到自己某方面能力的不足，所以这段时间去参加培训、给自己充电，提升一下自己某一方面的技能，为了更好的开展下一份工作；

家人生病了，急需自己的照顾，现在家人康复了，家里的事情也已经安排妥当，另外，在此期间自己也在不断地充电，我可以踏踏实实地上班；

6个月以上

6个月以上，这个时间有点长，因此，最重要的是要说明自己并没有脱离职场，比如做了一些和工作性质相关的兼职工作，空窗期时间长也可以围绕生孩子或者生病去说，因为这种理由似乎让人无法拒绝，毕竟每个家庭总有一些属于自己的小插曲。另外，如果还可以围绕着自己在和职业相关的领域创业，现在创业失败了，经历过之后，想踏踏实实地回归职场干活。

总结

离开职场容易，回归职场难，因此，如果没有什么特殊原因，不建议离职后的空窗期太长。另外，空窗期长并不代表求职者的能力差，不管是什么原因导致空窗期我们都应该给面试官展示积极的一面，作为面试官，我们也应该从打工人的无奈出发，只要不是太离谱，就不要太计较。

作者：猿java
来源：juejin.cn/post/7380268230797901864

收起阅读 »

Echarts中国地图下钻，支持下钻到县（vue3）

web

引言 Echarts 大家都不陌生吧，时常被用于绘制各种图表，也作为大屏可视化的常驻用户，这里就不多说了，今天主要是讲述一下 Echarts 的地图下钻，支持下钻到县、返回上一级。准备工作地图JSON数据 DataV.GeoAtlas地理小工具系列 (al...

继续阅读 »

引言

Echarts 大家都不陌生吧，时常被用于绘制各种图表，也作为大屏可视化的常驻用户，这里就不多说了，今天主要是讲述一下 Echarts 的地图下钻，支持下钻到县、返回上一级。

准备工作

地图JSON数据

DataV.GeoAtlas地理小工具系列 (aliyun.com) 支持在线调用API和下载json资源（我这里是调用的API）

如果地图json API请求报错403，可参考这个解决办法：地图请求阿里的geojson数据时，返回403Forbidden解决方案

技术栈

vue: 3.3.7

vue-echarts: 6.6.1 （直接使用 Echarts 也是一样的，这个只是对 Echarts 的组件封装）

vite: 4.5.0

地图效果

项目预览地址：UnusualAdmin

项目代码地址：UnusualAdmin

实现

template

这里只需要一个 Echarts 节点和一个按钮就行了

<template>

  <div :style="`height: ${calcHeight('main')};`" class="wh-full pos-relative">

    <v-chart :option="mapOption" :autoresize="true" @click="handleClick" />

    <n-button v-show="isShowBack" class="pos-absolute top-10 left-10" @click="goBack">返回n-button>

  div>

template>

获取mapJson

// 使用线上API

const getMapJson = async (mapName: string) => {

  const url = `https://geo.datav.aliyun.com/areas_v3/bound/${mapName}.json`

  const mapJson = await fetch(url).then(res => res.json())

  return mapJson

}



// 使用本地资源

const getMapJson = async (mapName: string) => {

  const url = `@/assets/mapJson/${mapName}.json`

  const mapJson = await import(/* @vite-ignore */ url)

  return mapJson

}

第二种方法（使用本地资源）存在问题：这个方法后续发现，vite打包不会把json文件打包到dist，线上会报错，目前没找到可靠的解决办法（如果放到public文件夹下会打包进去）,故舍弃。

如果大家有什么解决这个问题的好办法，请在评论区留言，博主会一一去尝试的🙏🙏🙏

更新地图配置options

const setOptions = (mapName: string, mapData: any) => {

  return {

     // 鼠标悬浮提示

    tooltip: {

      show: true,

      formatter: function (params: any) {

        // 根据需要进行数据处理或格式化操作

        if (params && params.data) {

          const { adcode, name, data } = params.data;

          // 返回自定义的tooltip内容

          return `adcode: ${adcode}
name: ${name}
data: ${data}`;

        }

      },

    },

    // 左下角的数据颜色条

    visualMap: {

      show: true,

      min: 0,

      max: 100,

      left: 'left',

      top: 'bottom',

      text: ['高', '低'], // 文本，默认为数值文本

      calculable: true,

      seriesIndex: [0],

      inRange: {

        color: ['#00467F', '#A5CC82'] // 蓝绿

      }

    },

    // geo地图

    geo: {

      map: mapName,

      roam: true,

      select: false,

      // 图形上的文本标签，可用于说明图形的一些数据信息，比如值，名称等。

      selectedMode: 'single',

      label: {

        show: true

      },

      emphasis: {

        itemStyle: {

          areaColor: '#389BB7',

          borderColor: '#389BB7',

          borderWidth: 0

        },

        label: {

          fontSize: 14,

        },

      }

    },

    series: [

      // 地图数据

      {

        type: 'map',

        map: mapName,

        roam: true,

        geoIndex: 0,

        select: false,

        data: mapData

      },

      // 散点

      {

        name: '散点',

        type: 'scatter',

        coordinateSystem: 'geo',

        data: mapData,

        itemStyle: {

          color: '#05C3F9'

        }

      },

      // 气泡点

      {

        name: '点',

        type: 'scatter',

        coordinateSystem: 'geo',

        symbol: 'pin', //气泡

        symbolSize: function (val: any) {

          if (val) {

            return val[2] / 4 + 20;

          }

        },

        label: {

          show: true,

          formatter: function (params: any) {

            return params.data.data || 0;

          },

          color: '#fff',

          fontSize: 9,

        },

        itemStyle: {

          color: '#F62157', //标志颜色

        },

        zlevel: 6,

        data: mapData,

      },

      // 地图标点

      {

        name: 'Top 5',

        type: 'effectScatter',

        coordinateSystem: 'geo',

        data: mapData.map((item: { data: number }) => {

          if (item.data > 60) return item

        }),

        symbolSize: 15,

        showEffectOn: 'render',

        rippleEffect: {

          brushType: 'stroke'

        },

        label: {

          formatter: '{b}',

          position: 'right',

          show: true

        },

        itemStyle: {

          color: 'yellow',

          shadowBlur: 10,

          shadowColor: 'yellow'

        },

        zlevel: 1

      },

    ]

  }

}

渲染地图

const renderMapEcharts = async (mapName: string) => {

  const mapJson = await getMapJson(mapName)

  registerMap(mapName, mapJson); // 注册地图

  // 为地图生成一些随机数据

  const mapdata = mapJson.features.map((item: { properties: any }) => {

    const data = (Math.random() * 80 + 20).toFixed(0) // 20-80随机数

    const tempValue = item.properties.center ? [...item.properties.center, data] : item.properties.center

    return {

      name: item.properties.name,

      value: tempValue, // 中心点经纬度

      adcode: item.properties.adcode, // 区域编码

      level: item.properties.level, // 层级

      data // 模拟数据

    }

  });

  // 更新地图options

  mapOption.value = setOptions(mapName, mapdata)

}

实现地图点击下钻

// 点击下砖

const mapList = ref<string[]>([]) // 记录地图

const handleClick = (param: any) => {

  // 只有点击地图才触发

  if (param.seriesType !== 'map') return

  const { adcode, level } = param.data

  const mapName = level === 'district' ? adcode : adcode + '_full'

  // 防止最后一个层级被重复点击，返回上一级出错

  if (mapList.value[mapList.value.length - 1] === mapName) {

    return notification.warning({ content: '已经是最下层了', duration: 1000 })

  }

  // 每次下转都记录下地图的name，在返回的时候使用

  mapList.value.push(mapName)

  renderMapEcharts(mapName)

}

返回上一级实现

// 点击返回上一级地图

const goBack = () => {

  const mapName = mapList.value[mapList.value.length - 2] || '100000_full'

  mapList.value.pop()

  renderMapEcharts(mapName)

}

全部代码

<template>
  <div :style="`height: ${calcHeight('main')};`" class="wh-full pos-relative">
    <v-chart :option="mapOption" :autoresize="true" @click="handleClick" />
    <n-button v-show="isShowBack" class="pos-absolute top-10 left-10" @click="goBack">返回</n-button>
  </div>
</template>

<script setup lang="ts" name="EchartsMap">
import { use, registerMap } from 'echarts/core'
import VChart from 'vue-echarts'
import { CanvasRenderer } from 'echarts/renderers'
import { MapChart, ScatterChart, EffectScatterChart } from 'echarts/charts'
import { TitleComponent, TooltipComponent, LegendComponent, GridComponent, VisualMapComponent } from 'echarts/components'
import { calcHeight } from '@/utils/help';

use([
  CanvasRenderer,
  TitleComponent,
  TooltipComponent,
  LegendComponent,
  GridComponent,
  VisualMapComponent,
  MapChart,
  ScatterChart,
  EffectScatterChart
])

const notification = useNotification()
const mapOption = ref()
const mapList = ref<string[]>([]) // 记录地图
const isShowBack = computed(() => {
  return mapList.value.length !== 0
})

const getMapJson = async (mapName: string) => {
  const url = `https://geo.datav.aliyun.com/areas_v3/bound/${mapName}.json`
  const mapJson = await fetch(url).then(res => res.json())
  return mapJson
}

const setOptions = (mapName: string, mapData: any) => {
  return {
    tooltip: {
      show: true,
      formatter: function (params: any) {
        // 根据需要进行数据处理或格式化操作
        if (params && params.data) {
          const { adcode, name, data } = params.data;
          // 返回自定义的tooltip内容
          return `adcode: ${adcode}<br>name: ${name}<br>data: ${data}`;
        }
      },
    },
    visualMap: {
      show: true,
      min: 0,
      max: 100,
      left: 'left',
      top: 'bottom',
      text: ['高', '低'], // 文本，默认为数值文本
      calculable: true,
      seriesIndex: [0],
      inRange: {
        color: ['#00467F', '#A5CC82'] // 蓝绿
      }
    },
    geo: {
      map: mapName,
      roam: true,
      select: false,
      // zoom: 1.6,
      // layoutCenter: ['45%', '70%'],
      // layoutSize: 750,
      // 图形上的文本标签，可用于说明图形的一些数据信息，比如值，名称等。
      selectedMode: 'single',
      label: {
        show: true
      },
      emphasis: {
        itemStyle: {
          areaColor: '#389BB7',
          borderColor: '#389BB7',
          borderWidth: 0
        },
        label: {
          fontSize: 14,
        },
      }
    },
    series: [
      // 数据
      {
        type: 'map',
        map: mapName,
        roam: true,
        geoIndex: 0,
        select: false,
        data: mapData
      },
      {
        name: '散点',
        type: 'scatter',
        coordinateSystem: 'geo',
        data: mapData,
        itemStyle: {
          color: '#05C3F9'
        }
      },
      {
        name: '点',
        type: 'scatter',
        coordinateSystem: 'geo',
        symbol: 'pin', //气泡
        symbolSize: function (val: any) {
          if (val) {
            return val[2] / 4 + 20;
          }
        },
        label: {
          show: true,
          formatter: function (params: any) {
            return params.data.data || 0;
          },
          color: '#fff',
          fontSize: 9,
        },
        itemStyle: {
          color: '#F62157', //标志颜色
        },
        zlevel: 6,
        data: mapData,
      },
      {
        name: 'Top 5',
        type: 'effectScatter',
        coordinateSystem: 'geo',
        data: mapData.map((item: { data: number }) => {
          if (item.data > 60) return item
        }),
        symbolSize: 15,
        showEffectOn: 'render',
        rippleEffect: {
          brushType: 'stroke'
        },
        label: {
          formatter: '{b}',
          position: 'right',
          show: true
        },
        itemStyle: {
          color: 'yellow',
          shadowBlur: 10,
          shadowColor: 'yellow'
        },
        zlevel: 1
      },
    ]
  }
}

const renderMapEcharts = async (mapName: string) => {
  const mapJson = await getMapJson(mapName)
  registerMap(mapName, mapJson);
  const mapdata = mapJson.features.map((item: { properties: any }) => {
    const data = (Math.random() * 80 + 20).toFixed(0) // 20-80随机数
    const tempValue = item.properties.center ? [...item.properties.center, data] : item.properties.center
    return {
      name: item.properties.name,
      value: tempValue, // 中心点经纬度
      adcode: item.properties.adcode, // 区域编码
      level: item.properties.level, // 层级
      data // 模拟数据
    }
  });
  mapOption.value = setOptions(mapName, mapdata)
}

renderMapEcharts('100000_full') // 初始化绘制中国地图

// 点击下砖
const handleClick = (param: any) => {
  // 只有点击地图才触发
  if (param.seriesType !== 'map') return
  const { adcode, level } = param.data
  const mapName = level === 'district' ? adcode : adcode + '_full'
  // 防止最后一个层级被重复点击，返回上一级出错
  if (mapList.value[mapList.value.length - 1] === mapName) {
    return notification.warning({ content: '已经是最下层了', duration: 1000 })
  }
  mapList.value.push(mapName)
  renderMapEcharts(mapName)
}

// 点击返回上一级地图
const goBack = () => {
  const mapName = mapList.value[mapList.value.length - 2] || '100000_full'
  mapList.value.pop()
  renderMapEcharts(mapName)
}
</script>

作者：树深遇鹿
来源：juejin.cn/post/7371641968600383540

收起阅读 »

阿里也出手了！Spring CloudAlibaba AI问世了

Java

写在前面在之前的文章中我们有介绍过SpringAI这个项目。SpringAI 是Spring 官方社区项目，旨在简化 Java AI 应用程序开发，让 Java 开发者像使用 Spring 开发普通应用一样开发 AI 应用。而SpringAI 主要面向的...

继续阅读 »

写在前面

在之前的文章中我们有介绍过SpringAI这个项目。SpringAI 是Spring 官方社区项目，旨在简化 Java AI 应用程序开发，

让 Java 开发者像使用 Spring 开发普通应用一样开发 AI 应用。

而SpringAI 主要面向的是国外的各种大模型接入，对于国内开发者可能不太友好。

于是乎，Spring Cloud Alibaba AI便问世了，Spring Cloud Alibaba AI以 Spring AI 为基础，并在此基础上提供阿里云通义系列大模型全面适配，

让用户在 5 分钟内开发基于通义大模型的 Java AI 应用。

一、Spring AI 简介

可能有些小伙伴已经忘记了SpringAI 是啥？我们这儿再来简单回顾一下。

Spring AI是一个面向AI工程的应用框架。其目标是将可移植性和模块化设计等设计原则应用于AI领域的Spring生态系统，

并将POJO作为应用程序的构建块推广到AI领域。

转换为人话来说就是：Spring出了一个AI框架，帮助我们快速调用AI，从而实现各种功能场景。

二、Spring Cloud Alibaba AI 简介

Spring Cloud Alibaba AI 以 Spring AI 为基础，并在此基础上，基于 Spring AI 0.8.1 版本 API 完成通义系列大模型的接入

实现阿里云通义系列大模型全面适配。

在当前最新版本中，Spring Cloud Alibaba AI 主要完成了几种常见生成式模型的适配，包括对话、文生图、文生语音等，

开发者可以使用 Spring Cloud Alibaba AI 开发基于通义的聊天、图片或语音生成 AI 应用，

框架还提供 OutParser、Prompt Template、Stuff 等实用能力。

三、第一个Spring AI应用开发

① 新建maven 项目

注：在创建项目的时候，jdk版本必须选择17+

② 添加依赖

<dependency>

    <groupId>com.alibaba.cloud</groupId>

    <artifactId>spring-cloud-alibaba-dependencies</artifactId>

    <version>2023.0.1.0</version>

    <type>pom</type>

    <scope>import</scope>

</dependency>



<dependency>

    <groupId>com.alibaba.cloud</groupId>

    <artifactId>spring-cloud-starter-alibaba-ai</artifactId>

    <version>2023.0.1.0</version>

</dependency>

注：这里我们需要配置镜像源，否则是没法下载依赖的。会报如下错误

spring-ai: 0.8.1 dependency not found

<repositories>

    <repository>

        <id>spring-milestones</id>

        <name>Spring Milestones</name>

        <url>https://repo.spring.io/milestone</url>

        <snapshots>

            <enabled>false</enabled>

        </snapshots>

    </repository>

</repositories>

③ 在 application.yml 配置文件中添加api-key

spring:

  cloud:

    ai:

      tongyi:

        api-key: 你自己申请的api-key

小伙伴如果不知道在哪申请，我把申请连接也放这儿了

dashscope.console.aliyun.com/apiKey

操作步骤：help.aliyun.com/zh/dashscop…

④ 新建TongYiController 类，代码如下

@RestController

@RequestMapping("/ai")

@CrossOrigin

@Slf4j

public class TongYiController {



    @Autowired

    @Qualifier("tongYiSimpleServiceImpl")

    private TongYiService tongYiSimpleService;



    @GetMapping("/example")

    public String completion(@RequestParam(value = "message", defaultValue = "Tell me a joke") String message) {



        return tongYiSimpleService.completion(message);

    }

    

}

⑤ 新建TongYiService 接口，代码如下

public interface TongYiService {

    String completion(String message);



}

⑥ 新建TongYiSimpleServiceImpl 实现类，代码如下

@Service

@Slf4j

public  class TongYiSimpleServiceImpl  implements TongYiService {



    private final ChatClient chatClient;



    @Autowired

    public TongYiSimpleServiceImpl(ChatClient chatClient, StreamingChatClient streamingChatClient) {

        this.chatClient = chatClient;

    }



    @Override

    public String completion(String message) {

        Prompt prompt = new Prompt(new UserMessage(message));



        return chatClient.call(prompt).getResult().getOutput().getContent();

    }





}

到这儿我们一个简单的AI应用已经开发完成了，最终项目结构如下

四、运行AI应用

启动服务，我们只需要在浏览器中输入：http://localhost:8080/ai/example 即可与AI交互。

① 不带message参数，则message=Tell me a joke,应用随机返回一个笑话

② 我们在浏览器中输入：http://localhost:8080/ai/example?message=对话内容

五、前端页面对话模式

我们只需要在resources/static 路径下添加一个index.html前端页面，即可拥有根据美观的交互体验。

index.html代码官方github仓库中已给出样例，由于代码比较长，这里就不贴代码了

github.com/alibaba/spr…

添加完静态页面之后，我们浏览器中输入：http://localhost:8080/index.html 就可以得到一个美观的交互界面

接下来，我们来实际体验一下

六、其他模型

上面章节中我们只简单体验了对话模型，阿里还有很多其他模型。由于篇幅原因这里就不一一带大家一起体验了。

应用场景：

各个模型概述：

七、怎么样快速接入大模型

各种应用场景阿里官方GitHub都给出了接入例子

github.com/alibaba/spr…

感兴趣的小伙伴可以自己到上面github 仓库看代码研究

本期内容到这儿就结束了，★,°:.☆(￣▽￣)/$: .°★ 。希望对您有所帮助

我们下期再见ヾ(•ω•`)o (●'◡'●)

作者：xiezhr
来源：juejin.cn/post/7380771735681941523

收起阅读 »

threejs渲染高级感可视化风力发电车模型

web

本文使用threejs开发一款风力发电机物联可视化系统，包含着色器效果、动画、补间动画和开发过程中使用模型材质遇到的问题，内含大量gif效果图，视频讲解及源码见文末技术栈 three.js 0.165.0 vite 4.3.2 nodej...

继续阅读 »

本文使用threejs开发一款风力发电机物联可视化系统，包含着色器效果、动画、补间动画和开发过程中使用模型材质遇到的问题，内含大量gif效果图，

视频讲解及源码见文末

技术栈

three.js 0.165.0

vite 4.3.2

nodejs v18.19.0

效果图

一镜到底动画

切割动画

线稿动画

外壳透明度动画

展开齿轮动画

发光线条动画

代码及功能介绍

着色器

文中用到一个着色器，就是给模型增加光感的动态光影

创建顶点着色器 vertexShader:

varying vec2 vUv;

void main() {

    vUv = uv;

    gl_Position = projectionMatrix * modelViewMatrix * vec4(position, 1.0);

}

创建片元着色器 vertexShader:

varying vec2 vUv;

uniform vec2 u_center; // 添加这一行  



void main() {

    // 泡泡颜色

    vec3 bubbleColor = vec3(0.9, 0.9, 0.9); // 乳白色

    // 泡泡中心位置

   vec2 center = u_center;  

    // 计算当前像素到泡泡中心的距离

    float distanceToCenter = distance(vUv, center);

    // 计算透明度，可以根据实际需要调整

    float alpha = smoothstep(0.1, 0.0, distanceToCenter);



    gl_FragColor = vec4(bubbleColor, alpha);

创建着色器材质 bubbleMaterial

export const bubbleMaterial = new THREE.ShaderMaterial({

    vertexShader: vertexShader,

    fragmentShader: fragmentShader,

    transparent: true, // 开启透明

    depthTest: true, // 开启深度测试

    depthWrite: false, // 不写入深度缓冲

    uniforms: {

        u_center: { value: new THREE.Vector2(0.3, 0.3) } // 添加这一行  

    },

});

从代码中可以看到 uniform声明了一个变量u_center，目的是为了在render方法中动态修改中心位置，从而实现动态光效的效果，

具体引用 render 方法中

 // 更新中心位置（例如，每一帧都改变）  

    let t = performance.now() * 0.001; 

    bubbleMaterial.uniforms.u_center.value.x = Math.sin(t) * 0.5 + 0.5; // x 位置基于时间变化  

    bubbleMaterial.uniforms.u_center.value.y = Math.cos(t) * 0.5 + 0.5; // y 位置基于时间变化

官网案例 # Uniform，详细介绍了uniform的使用方法，支持通过变量对着色器材质中的属性进行改变

从模型上可能看不出什么，下面的图是在一个圆球上加的这个效果

着色器中有几个参数可以自定义也可以自己修改， float alpha = smoothstep(0.6, 0.0, distanceToCenter);中的smoothstep 是一个常用的函数，用于在两个值之间进行平滑插值。具体来说，smoothstep(edge0, edge1, x) 函数会计算 x 在 edge0 和 edge1 之间的平滑过渡值。当 x 小于 edge0 时，返回值为 0；当 x 大于 edge1 时，返回值为 1；而当 x 在 edge0 和 edge1 之间时，它返回一个在 0 和 1 之间的平滑过渡值。

切割动画

切割动画使用的是数学库平面THREE.Plane和属性 constant，通过修改constant值即可实现动画，从normal法向量起至constant的距离为可展示内容。

从原点到平面的有符号距离。默认值为 0.

constant取模型的box3包围盒的min值，至max值做补间动画，以下是代码示意

const wind = windGltf.scene

const boxInfo = wind.userData.box3Info;



const max = boxInfo.worldPosition.z + boxInfo.max.z

const min = boxInfo.worldPosition.z + boxInfo.min.z

    

let tween = new TWEEN.Tween({ d: min - 0.2 })

    .to({ d: max + 0.1 }, 1000 * 2)

    .start()

    .onUpdate(({ d }) => {

        clippingPlane.constant = d

    })

详看切割效果图

图中添加了切割线的辅助线，可以通过右侧的操作面板显示或隐藏。

模型材质需要注意的问题

由于齿轮在风车的内容部，并且风车模型开启了transparent=true，那么计算透明度深度就会出现问题，首先要设置 depthWrite = true，开启深度缓存区，renderOrder = -1，

这个值将使得scene graph（场景图）中默认的的渲染顺序被覆盖，即使不透明对象和透明对象保持独立顺序。渲染顺序是由低到高来排序的，默认值为0。

threejs的透明材质渲染和不透明材质渲染的时候，会互相影响，而调整renderOrder顺序则可以让透明对象和不透明对象相对独立的渲染。

depthWrite对比

renderOrder 对比

自定义动画贝塞尔曲线

众所周知，贝塞尔曲线通常用于调整关键帧动画，创建平滑的、曲线的运动路径。本文中使用的tweenjs就内置了众多的运动曲线easing(easingFunction?: EasingFunction): this;类型，虽然有很多内置，但是毕竟需求是无限的，接下来介绍的方法就是可以自己设置动画的贝塞尔曲线，来控制动画的执行曲线。

具体使用

// 使用示例

const controlPoints = [    { x: 0 },    { x: 0.5 },    { x: 2 },    { x: 1 }];

const cubicBezier = new CubicBezier(controlPoints[0], controlPoints[1], controlPoints[2], controlPoints[3]);



let tween = new TWEEN.Tween(edgeLineGr0up.scale)

.to(windGltf.scene.scale.clone().set(1, 1, 1), 1000 * 2)

.easing((t) => {

    return cubicBezier.get(t).x

})

.start()

.onComplete(() => {

    lineOpacityAction(0.3)

    res({ tween })

})

在tween的easing的回调中添加一个方法，方法中调用了cubicBezier，下面就介绍一下这个方法

源码

[p0] – 起点  

[p1] – 第一个控制点  

[p2] – 第二个控制点  

[p3] – 终点

export class CubicBezier {

    private p0: { x: number; };

    private p1: { x: number; };

    private p2: { x: number; };

    private p3: { x: number; };



    constructor(p0: { x: number; }, p1: { x: number; }, p2: { x: number; }, p3: { x: number; }) {

        this.p0 = p0;

        this.p1 = p1;

        this.p2 = p2;

        this.p3 = p3;

    }



    get(t: number): { x: number; } {

        const p0 = this.p0;

        const p1 = this.p1;

        const p2 = this.p2;

        const p3 = this.p3;



        const mt = 1 - t;

        const mt2 = mt * mt;

        const mt3 = mt2 * mt;

        const t2 = t * t;

        const t3 = t2 * t;



        const x = mt3 * p0.x + 3 * mt2 * t * p1.x + 3 * mt * t2 * p2.x + t3 * p3.x;



        return { x };

    }

}

类CubicBezier支持get方法，通过四个关键点位信息，绘制三次贝塞尔曲线，参数t在0到1之间变化，当t从0变化到1时，曲线上的点从p0平滑地过渡到p3。

mt = 1 - t;：这是t的补数（1减去t）。
mt2 = mt * mt; 和 mt3 = mt2 * mt;：计算mt的平方和立方。
t2 = t * t; 和 t3 = t2 * t;：计算t的平方和立方。

这是通过取四个点的x坐标的加权和来完成的，其中权重是基于t的幂的。具体来说，p0的权重是(1-t)^3，p1的权重是3 * (1-t)^2 * t，p2的权重是3 * (1-t) * t^2，而p3的权重是t^3。

{ x: 0 },{ x: 0.5 },{ x: 2 },{ x: 1 } 这组数据形成的曲线效果是由start参数到end的两倍参数再到end参数

具体效果如下

齿轮

齿轮动画

模型中自带动画

源码中有一整套的动画播放类方法，HandleAnimation，其中功能包含播放训话动画，切换动画，播放一次动画，绘制骨骼，镜头跟随等功能。

具体使用方法：

   // 齿轮动画

     /**

     * 

     * @param model 动画模型

     * @param animations 动画合集

     */

    motorAnimation = new HandleAnimation(motorGltf.scene, motorGltf.animations)

    // 播放动画 take 001 是默认动画名称

    motorAnimation.play('Take 001')

在render中调用

motorAnimation && motorAnimation.upDate()

齿轮展开（补间动画）

补间动画在齿轮展开时调用，使用的tweenjs，这里讲一下定位运动后的模型位置，使用# 变换控制器（TransformControls），代码中有封装好的完整的使用方法，在TransformControls.ts中，包含同时存在轨道控制器时与变换控制器对场景操作冲突时的处理。

使用方法：

/**

 * @param mesh 受控模型

 * @param draggingChangedCallback  操控回调

 */

 TransformControls(mesh, ()=>{

    console.log(mesh.position)

})

齿轮发光

发光效果方法封装在utls/index.ts中的unreal方法，使用的是threejs提供的虚幻发光通道RenderPass,UnrealBloomPass,以及合成器EffectComposer，方法接受参数如下



// params 默认参数

const createParams = {

    threshold: 0,

    strength: 0.972, // 强度

    radius: 0.21,// 半径

    exposure: 1.55 // 扩散

};



/**

 * 

 * @param scene 渲染场景

 * @param camera 镜头

 * @param renderer 渲染器

 * @param width 需要发光位置的宽度

 * @param height 发光位置的高度

 * @param params 发光参数

 * @returns 

 */

调用方法如下：



const { finalComposer: F,

       bloomComposer: B,

       renderScene: R, bloomPass: BP } = unreal(scene, camera, renderer, width, height, params)

    finalComposer = F

    bloomComposer = B

    renderScene = R

    bloomPass = BP

    bloomPass.threshold = 0

除了调用方法还有一些需要调整的地方，比如发光时模型什么材质，又或者不发光时又是什么材质，这里需要单独定义，并在render渲染函数中调用

 if (guiParams.isLight) {

        if (bloomComposer) {

            scene.traverse(darkenNonBloomed.bind(this));

            bloomComposer.render();

        }

        if (finalComposer) {

            scene.traverse(restoreMaterial.bind(this));

            finalComposer.render();

        }

    }

在scene.traverse的回调中，检验模型是否为发光体，再进行材质的更换，这里用的标识是 object.userData.isLight为true时，判定该物体为发光物体。其他物体则不发光

回调方法

function darkenNonBloomed(obj: THREE.Mesh) {

    if (bloomLayer) {

        if (!obj.userData.isLight && bloomLayer.test(obj.layers) === false) {

            materials[obj.uuid] = obj.material;

            obj.material = darkMaterial;

        }

    }



}



function restoreMaterial(obj: THREE.Mesh) {

    if (materials[obj.uuid]) {

        obj.material = materials[obj.uuid];

        // 用于删除没必要的渲染

        delete materials[obj.uuid];

    }

}

再场景的右上角我们新增了几个参数，用来调整线条的发光效果，下面通过动图看一下，图片有点大，请耐心等待加载

好啦，本篇文章到此，如看源码有不明白的地方，可私信~

最近正在筹备工具库，以上可视化常用的方法都将涵盖在里面

历史文章

three.js——商场楼宇室内导航系统内附源码

three.js——可视化高级涡轮效果+警报效果内附源码

高德地图巡航功能内附源码

three.js——3d塔防游戏内附源码

three.js+物理引擎——跨越障碍的汽车可操作可演示

百度地图——如何计算地球任意两点之间距离内附源码

threejs——可视化地球可操作可定位

three.js 专栏

源码及讲解

源码 http://www.aspiringcode.com/content?id=…

体验地址：display.aspiringcode.com:8888/html/171422…

B站讲解地址：【threejs渲染高级感可视化风力发电车模型】 http://www.bilibili.com/video/BV1gT…

作者：孙_华鹏
来源：juejin.cn/post/7379906492038889512

收起阅读 »

前端太卷了，不玩了，写写node.js全栈涨工资，赶紧学起来吧！！！！！

web

如果你感觉到累了，卷不动了，那就来看这篇文章吧，写写全栈，涨涨工资，吹吹牛皮！人生得意须尽欢，不要只想忙搬砖！首先聊下node.js的优缺点和应用场景Node.js的优点和应用场景Node.js作为后端开发的选择具有许多优点，以下是其中一些：高性能： ...

继续阅读 »

如果你感觉到累了，卷不动了，那就来看这篇文章吧，写写全栈，涨涨工资，吹吹牛皮！人生得意须尽欢，不要只想忙搬砖！

首先聊下node.js的优缺点和应用场景

Node.js的优点和应用场景

Node.js作为后端开发的选择具有许多优点，以下是其中一些：

高性能： Node.js采用了事件驱动、非阻塞I/O模型，使得它能够处理大量并发请求而不会阻塞线程，从而具有出色的性能表现。
轻量级和高效： Node.js的设计简洁而轻量，启动速度快，内存占用低，适合构建轻量级、高效的应用程序。
JavaScript全栈：使用Node.js，开发者可以使用同一种语言（JavaScript）进行前后端开发，简化了开发人员的学习成本和代码维护成本。
丰富的生态系统： Node.js拥有丰富的第三方模块和库，可以轻松集成各种功能和服务，提高开发效率。
可扩展性： Node.js具有良好的可扩展性，可以通过添加更多的服务器实例来横向扩展应用程序，满足不断增长的用户需求。
实时应用：由于Node.js对于事件驱动和非阻塞I/O的支持，它非常适合构建实时应用，如即时通讯、在线游戏、实时分析等。
微服务架构： Node.js可以作为微服务架构中的一个服务组件，通过轻量级的设计和快速的响应能力，使得微服务之间的通信更加高效。
数据流处理： Node.js适合处理大量的数据流，例如文件操作、网络流量分析等，可以通过流式处理来有效地管理和处理数据。

应用场景包括但不限于：

Web应用程序：开发基于Node.js的Web应用程序，如社交网络、电子商务平台、博客、内容管理系统等。
API服务：使用Node.js构建RESTful API服务，为移动应用、前端应用提供数据接口。
实时应用：构建实时应用程序，如聊天应用、在线游戏、实时地图等，利用Node.js的事件驱动和非阻塞I/O模型实现高效的实时通讯。
数据流处理：使用Node.js处理大量的数据流，例如日志处理、实时监控、数据分析等。
微服务架构：将Node.js作为微服务架构中的一个服务组件，通过轻量级的设计和快速的响应能力，实现服务之间的高效通信。

总的来说，Node.js作为一种高性能、轻量级的后端开发工具，适用于各种类型的应用场景，尤其在需要处理大量并发请求和实时通讯的应用中表现突出。

node.js的局限性

尽管Node.js在许多方面都表现出色，但它也有一些局限性和适用场景的限制。以下是一些Node.js的局限性：

单线程阻塞：虽然Node.js采用了非阻塞I/O的模型，但在处理CPU密集型任务时，单线程的特性可能导致性能瓶颈。由于Node.js是单线程的，处理阻塞操作（如大量计算或长时间的同步操作）会影响整个应用程序的响应性。
回调地狱（Callback Hell）：在复杂的异步操作中，嵌套的回调函数可能导致代码难以理解和维护，这被称为“回调地狱”问题。虽然可以使用Promise、async/await等来缓解这个问题，但在某些情况下仍可能存在。
相对较小的标准库： Node.js的标准库相对较小，相比于其他后端语言，需要依赖第三方模块来实现一些常见的功能。这可能需要花费额外的时间来选择、学习和整合这些模块。
不适合密集型计算：由于Node.js是单线程的，不适合用于处理大量的计算密集型任务。如果应用程序主要依赖于大量的数学计算或复杂的数据处理，其他多线程的语言可能更合适。
Callback错误处理：在回调模式下，错误处理可能变得繁琐，需要在每个回调中检查错误对象。这使得开发者需要更加小心地处理错误，以确保它们不会被忽略。
相对较新的技术栈：相较于一些传统的后端技术栈，Node.js是相对较新的技术，一些企业可能仍然更倾向于使用更成熟的技术。
不适合长连接：对于长连接的应用场景，如传统的即时通讯（IM）系统，Node.js的单线程模型可能不是最佳选择，因为它会导致长时间占用一个线程。

尽管有这些局限性，但Node.js在许多应用场景下仍然是一个强大且高效的工具。选择使用Node.js还是其他后端技术应该根据具体项目的需求、团队的技术栈和开发者的经验来做出。

node.js常用的几种主流框架

Node.js是一个非常灵活的JavaScript运行时环境，它可以用于构建各种类型的应用程序，从简单的命令行工具到大型的网络应用程序。以下是一些常用的Node.js框架：

Express.js：Express.js是Node.js最流行的Web应用程序框架之一，它提供了一组强大的功能，使得构建Web应用变得更加简单和快速。Express.js具有路由、中间件、模板引擎等功能，可以满足大多数Web应用的需求。
Koa.js：Koa.js是由Express.js原班人马打造的下一代Node.js Web框架，它使用了ES6的新特性，如async/await，使得编写异步代码更加简洁。Koa.js更加轻量级和灵活，它提供了更强大的中间件功能，可以更方便地实现定制化的功能。
Nest.js：Nest.js是一个用于构建高效、可扩展的服务器端应用程序的渐进式Node.js框架。它基于Express.js，但引入了许多现代化的概念，如依赖注入、模块化、类型检查等，使得构建复杂应用变得更加简单。
Hapi.js：Hapi.js是一个专注于提供配置简单、可测试性强的Web服务器框架。它提供了一系列的插件，可以轻松地扩展其功能，同时具有强大的路由、验证、缓存等功能，适用于构建大型和高可靠性的Web应用程序。
Meteor.js：Meteor.js是一个全栈JavaScript框架，它可以同时构建客户端和服务器端的应用程序。Meteor.js提供了一整套的工具和库，包括数据库访问、实时数据同步、用户认证等功能，使得构建实时Web应用变得更加简单和快速。
Sails.js：Sails.js是一个基于Express.js的MVC框架，它提供了类似于Ruby on Rails的开发体验，使得构建数据驱动的Web应用变得更加简单。Sails.js具有自动生成API、蓝图路由、数据关联等功能，适用于构建RESTful API和实时Web应用。

Express框架：实践与技术探索

1. Express框架简介：

Express是一个轻量级且灵活的Node.js Web应用程序框架，它提供了一组简洁而强大的工具，帮助开发者快速构建Web应用。Express的核心理念是中间件，通过中间件可以处理HTTP请求、响应以及应用程序的逻辑。

2. 基础搭建与路由：

在开始实践之前，首先需要搭建Express应用程序的基础结构。通过使用express-generator工具或手动创建package.json和app.js文件，可以快速启动一个Express项目。接下来，我们将学习如何定义路由以及如何处理HTTP请求和响应。

const express = require('express');

const app = express();



app.get('/', (req, res) => {

  res.send('Hello World!');

});



app.listen(3000, () => {

  console.log('Express app listening on port 3000');

});

3. 中间件：

Express中间件是一个函数，它可以访问请求对象（req）、响应对象（res）以及应用程序的下一个中间件函数（通常命名为next）。中间件函数可以用来执行任何代码，修改请求和响应对象，以及终止请求-响应周期。

app.use((req, res, next) => {

  console.log('Time:', Date.now());

  next();

});

4. 模板引擎与视图：

Express框架允许使用各种模板引擎来生成动态HTML内容。常用的模板引擎包括EJS、Pug和Handlebars。通过配置模板引擎，可以将动态数据嵌入到静态模板中，以生成最终的HTML页面。

app.set('view engine', 'ejs');

5. 数据库集成与ORM：

在实际应用中，数据库是不可或缺的一部分。Express框架与各种数据库集成良好，可以通过ORM（对象关系映射）工具来简化数据库操作。常用的ORM工具包括Sequelize、Mongoose等，它们可以帮助开发者更轻松地进行数据模型定义、查询和操作。

6. RESTful API设计与实现：

Express框架非常适合构建RESTful API。通过定义不同的HTTP动词和路由，可以实现资源的创建、读取、更新和删除操作。此外，Express还提供了一系列中间件来处理请求体、响应格式等，使得构建API变得更加简单。

app.get('/api/users', (req, res) => {

  // 获取所有用户信息

});



app.post('/api/users', (req, res) => {

  // 创建新用户

});

7. 实践案例：

为了更好地理解Express框架的实践，我们将以一个简单的博客应用为例。在这个应用中，我们可以拓展一下用户的注册、登录、文章的创建和展示等功能，并且结合数据库和RESTful API设计。在这个示例中，我们将使用MongoDB作为数据库，并使用Mongoose作为MongoDB的对象建模工具。首先，确保您已经安装了Node.js``和MongoDB，并创建了一个名为blogApp的文件夹来存放我们的项目。

首先，在项目文件夹中初始化npm，并安装Express、Mongoose和body-parser依赖：

npm init -y

npm install express mongoose body-parser

在项目文件夹中创建app.js文件，并编写以下代码：

// 导入所需的模块

const express = require('express');

const bodyParser = require('body-parser');

const mongoose = require('mongoose');



// 连接MongoDB数据库

mongoose.connect('mongodb://localhost:27017/blog', { useNewUrlParser: true, useUnifiedTopology: true });

const db = mongoose.connection;



// 检测数据库连接状态

db.on('error', console.error.bind(console, 'MongoDB connection error:'));

db.once('open', function() {

    console.log('Connected to MongoDB');

});



// 创建Express应用

const app = express();



// 使用body-parser中间件解析请求体

app.use(bodyParser.json());

app.use(bodyParser.urlencoded({ extended: true }));



// 定义用户模型

const User = mongoose.model('User', new mongoose.Schema({

    username: String,

    password: String

}));



// 注册用户

app.post('/api/register', async (req, res) => {

    try {

        const { username, password } = req.body;

        const user = await User.create({ username, password });

        res.json({ success: true, message: 'User registered successfully', user });

    } catch (error) {

        res.status(500).json({ success: false, message: error.message });

    }

});



// 用户登录

app.post('/api/login', async (req, res) => {

    try {

        const { username, password } = req.body;

        const user = await User.findOne({ username, password });

        if (user) {

            res.json({ success: true, message: 'User logged in successfully', user });

        } else {

            res.status(401).json({ success: false, message: 'Invalid username or password' });

        }

    } catch (error) {

        res.status(500).json({ success: false, message: error.message });

    }

});



// 启动Express服务器

const port = 3000;

app.listen(port, () => {

    console.log(`Server is running on port ${port}`);

});

以上代码实现了用户注册和登录的功能，使用了MongoDB作为数据库存储用户信息，并提供了RESTful风格的API接口。

您可以通过以下命令启动服务器：

node app.js

接下来，我们添加文章模型和相关的路由来实现文章的创建和展示功能。在app.js文件中添加以下代码：

// 定义文章模型

const Article = mongoose.model('Article', new mongoose.Schema({

    title: String,

    content: String,

    author: {

        type: mongoose.Schema.Types.ObjectId,

        ref: 'User'

    }

}));



// 创建文章

app.post('/api/articles', async (req, res) => {

    try {

        const { title, content, author } = req.body;

        const article = await Article.create({ title, content, author });

        res.json({ success: true, message: 'Article created successfully', article });

    } catch (error) {

        res.status(500).json({ success: false, message: error.message });

    }

});



// 获取所有文章

app.get('/api/articles', async (req, res) => {

    try {

        const articles = await Article.find().populate('author', 'username');

        res.json({ success: true, articles });

    } catch (error) {

        res.status(500).json({ success: false, message: error.message });

    }

});

以上代码实现了创建文章和获取所有文章的功能，每篇文章都与特定的作者相关联。

现在，您可以使用POST请求来创建新的用户和文章，使用GET请求来获取所有文章。例如：

注册新用户：发送POST请求到/api/register，传递username和password字段。
用户登录：发送POST请求到/api/login，传递username和password字段。
创建新文章：发送POST请求到/api/articles，传递title、content和author字段（注意，author字段应该是已注册用户的ID）。
获取所有文章：发送GET请求到/api/articles。

这个示例演示了如何使用Express框架结合MongoDB实现一个简单的博客应用，并提供了RESTful API接口。可以根据需求扩展和定制这个应用，例如添加用户身份验证、文章编辑和删除功能等。

看完后是不是觉得后端（CRUD）很简单，没错！就是这么简单！喜欢的小伙伴给个点赞加收藏，码字不易！

作者：为了WLB努力
来源：juejin.cn/post/7343138637971734569

收起阅读 »

反射为什么慢？

Java

1. 背景今天刷到一篇文章，标题是反射为什么慢，一下子懵逼了，确实没想过这个问题；盲猜了一下是由于反射实际上是做了一个代理的动作，导致执行的效率是小于直接实体类去调用方法的。 2. 文章给出的解释文章中给出的理由是因为以下4点：反射涉及动态解析的内容，...

继续阅读 »

1. 背景

今天刷到一篇文章，标题是反射为什么慢，一下子懵逼了，确实没想过这个问题；盲猜了一下是由于反射实际上是做了一个代理的动作，导致执行的效率是小于直接实体类去调用方法的。

2. 文章给出的解释

文章中给出的理由是因为以下4点：

反射涉及动态解析的内容，不能执行某些虚拟机优化，例如JIT优化技术

在反射时，参数需要包装成object[]类型，但是方法真正执行的时候，又使用拆包成真正的类型，这些动作不仅消耗时间，而且过程中会产生很多的对象，这就会导致gc，gc也会导致延时

反射的方法调用需要从数组中遍历，这个遍历的过程也比较消耗时间

不仅需要对方法的可见性进行检查，参数也需要做额外的检查

3. 结合实际理解

3.1 第一点分析

首先我们需要知道，java中的反射是一种机制，它可以在代码运行过程中，获取类的内部信息（变量、构造方法、成员方法）；操作对象的属性、方法。
然后关于反射的原理，首先我们需要知道一个java项目在启动之后，会将class文件加载到堆中，生成一个class对象，这个class对象中有一个类的所有信息，通过这个class对象获取类相关信息的操作我们称为反射。

其次是JIT优化技术，首先我们需要知道在java虚拟机中有两个角色，解释器和编译器；这两者各有优劣，首先是解释器可以在项目启动的时候直接直接发挥作用，省去编译的时候，立即执行，但是在执行效率上有所欠缺；在项目启动之后，随着时间推移，编译器逐渐将机器码编译成本地代码执行，减少解释器的中间损耗，增加了执行效率。

我们可以知道JIT优化通常依赖于在编译时能够知道的静态信息，而反射的动态性可能会破坏这些假设，使得JIT编译器难以进行有效的优化。

3.2 第二点

关于第二点，我们直接写一段反射调用对象方法的demo：

@Test

public void methodTest() {

    Class clazz = MyClass.class;



    try {

        //获取指定方法

        //这个注释的会报错 java.lang.NoSuchMethodException

        //Method back = clazz.getMethod("back");

        Method back = clazz.getMethod("back", String.class);

        Method say = clazz.getDeclaredMethod("say", String.class);

        //私有方法需要设置

        say.setAccessible(true);

        MyClass myClass = new MyClass("abc", 99);

        //反射调用方法

        System.out.println(back.invoke(myClass, "back"));



        say.invoke(myClass, "hello world");

    } catch (Exception e) {

        e.printStackTrace();

    }

}

在上面这段代码中，我们调用了一个invoke 方法，并且传了class对象和参数，进入到invoke方法中，我们可以看到invoke方法的入参都是Object类型的，args更是一个Object 数组，这就第二点，关于反射调用过程中的拆装箱。

@CallerSensitive

public Object invoke(Object obj, Object... args)

    throws IllegalAccessException, IllegalArgumentException,

        InvocationTargetException

{

    if (!override) {

        if (!Reflection.quickCheckMemberAccess(clazz, modifiers)) {

            Class<?> caller = Reflection.getCallerClass();

            checkAccess(caller, clazz, obj, modifiers);

        }

    }

    MethodAccessor ma = methodAccessor;             // read volatile

    if (ma == null) {

        ma = acquireMethodAccessor();

    }

    return ma.invoke(obj, args);

}

3.3 第三点

关于调用方法需要遍历这点，还是上面那个demo，我们在获取Method 对象的时候是通过调用getMethod、getDeclaredMethod方法，点击进入这个方法的源码，我们可以看到如下代码：

private static Method searchMethods(Method[] methods,

                                    String name,

                                    Class<?>[] parameterTypes)

{

    Method res = null;

    String internedName = name.intern();

    for (int i = 0; i < methods.length; i++) {

        Method m = methods[i];

        if (m.getName() == internedName

            && arrayContentsEq(parameterTypes, m.getParameterTypes())

            && (res == null

                || res.getReturnType().isAssignableFrom(m.getReturnType())))

            res = m;

    }



    return (res == null ? res : getReflectionFactory().copyMethod(res));

}

我们可以看到，底层实际上也是将class对象的所有method遍历了一遍，最终才拿到我们需要的方法的，这也就是第二点，执行具体方法的时候需要遍历class对象的方法。

3.4 第四点

第4点说需要对方法和参数进行检查，也就是我们在执行具体的某一个方法的时候，我们实际上是需要校验这个方法是否可见的，如果不可见，我们还需要将这个方法设置为可见，否则如果我们直接调用这个方法的话，会报错。

同时还有一个点，在我们调用invoke方法的时候，反射类会对方法和参数进行一个校验，让我们来看一下源码：

@CallerSensitive

public Object invoke(Object obj, Object... args)

    throws IllegalAccessException, IllegalArgumentException,

        InvocationTargetException

{

    if (!override) {

        if (!Reflection.quickCheckMemberAccess(clazz, modifiers)) {

            Class<?> caller = Reflection.getCallerClass();

            checkAccess(caller, clazz, obj, modifiers);

        }

    }

    MethodAccessor ma = methodAccessor;             // read volatile

    if (ma == null) {

        ma = acquireMethodAccessor();

    }

    return ma.invoke(obj, args);

}

我们可以看到还有quickCheckMemberAccess、checkAccess 等逻辑

4. 总结

平时在反射这块用的比较少，也没针对性的去学习一下。在工作之余，还是得保持一个学习的习惯，这样子才不会出现今天这种被一个问题难倒的情况，而且才能产出更多、更优秀的方案。

作者：喜欢小钱钱
来源：juejin.cn/post/7330115846140051496

收起阅读 »

听我一句劝，业务代码中，别用多线程。

Java

你好呀，我是歪歪。前几天我在网上冲浪，看到一个哥们在吐槽，说他工作三年多了，没使用过多线程。虽然八股文背的滚瓜烂熟，但是没有在实际开发过程中写的都是业务代码，没有使用过线程池，心里还是慌得一比。我只是微微一笑，这不是很正常吗？业务代码中一般也使不上多线...

继续阅读 »

你好呀，我是歪歪。

前几天我在网上冲浪，看到一个哥们在吐槽，说他工作三年多了，没使用过多线程。

虽然八股文背的滚瓜烂熟，但是没有在实际开发过程中写的都是业务代码，没有使用过线程池，心里还是慌得一比。

我只是微微一笑，这不是很正常吗？

业务代码中一般也使不上多线程，或者说，业务代码中不知不觉你以及在使用线程池了，你再 duang 的一下搞一个出来，反而容易出事。

所以提到线程池的时候，我个人的观点是必须把它吃得透透的，但是在业务代码中少用或者不用多线程。

关于这个观点，我给你盘一下。

Demo

首先我们还是花五分钟搭个 Demo 出来。

我手边刚好有一个之前搭的一个关于 Dubbo 的 Demo，消费者、生产者都有，我就直接拿来用了：

这个 Demo 我也是跟着网上的 quick start 搞的：

cn.dubbo.apache.org/zh-cn/overv…

可以说写的非常详细了，你就跟着官网的步骤一步步的搞就行了。

我这个 Demo 稍微不一样的是我在消费者模块里面搞了一个 Http 接口：

在接口里面发起了 RPC 调用，模拟从前端页面发起请求的场景，更加符合我们的开发习惯。

而官方的示例中，是基于了 SpringBoot 的 CommandLineRunner 去发起调用：

只是发起调用的方式不一样而已，其他没啥大区别。

需要说明的是，我只是手边刚好有一个 Dubbo 的 Demo，随手就拿来用了，但是本文想要表达的观点，和你使不使用 Dubbo 作为 RPC 框架，没有什么关系，道理是通用的。

上面这个 Demo 启动起来之后，通过 Http 接口发起一次调用，看到控制台服务提供方和服务消费方都有对应的日志输出，准备工作就算是齐活儿了：

上菜

在上面的 Demo 中，这是消费者的代码：

这是提供者的代码：

整个调用链路非常的清晰：

来，请你告诉我这里面有线程池吗？

没有！

是的，在日常的开发中，我就是写个接口给别人调用嘛，在我的接口里面并没有线程池相关的代码，只有 CRUD 相关的业务代码。

同时，在日常的开发中，我也经常调用别人提供给我的接口，也是一把梭，撸到底，根本就不会用到线程池。

所以，站在我，一个开发人员的角度，这个里面没有线程池。

合理，非常合理。

但是，当我们换个角度，再看看，它也是可以有的。

比如这样：

反应过来没有？

我们发起一个 Http 调用，是由一个 web 容器来处理这个请求的，你甭管它是 Tomcat，还是 Jetty、Netty、Undertow 这些玩意，反正是个 web 容器在处理。

那你说，这个里面有线程池吗？

在方法入口处打个断点，这个 http-nio-8081-exec-1 不就是 Tomcat 容器线程池里面的一个线程吗：

通过 dump 堆栈信息，过滤关键字可以看到这样的线程，在服务启动起来，啥也没干的情况下，一共有 10 个：

朋友，这不就是线程池吗？

虽然不是你写的，但是你确实用了。

我写出来的这个 test 接口，就是会由 web 容器中的一个线程来进行调用。所以，站在 web 容器的角度，这里是有一个线程池的：

同理，在 RPC 框架中，不管是消费方，还是服务提供方，也都存在着线程池。

比如 Dubbo 的线程池，你可以看一下官方的文档：

cn.dubbo.apache.org/zh-cn/overv…

而对于大多数的框架来说，它绝不可能只有一个线程池，为了做资源隔离，它会启用好几个线程池，达到线程池隔离，互不干扰的效果。

比如参与 Dubbo 一次调用的其实不仅一个线程池，至少还有 IO 线程池和业务线程池，它们各司其职：

我们主要关注这个业务线程池。

反正站在 Dubbo 框架的角度，又可以补充一下这个图片了：

那么问题来了，在当前的这个情况下？

当有人反馈：哎呀，这个服务吞吐量怎么上不去啊？

你怎么办？

你会 duang 的一下在业务逻辑里面加一个线程池吗？

大哥，前面有个 web 容器的线程池，后面有个框架的线程池，两头不调整，你在中间加个线程池，加它有啥用啊？

web 容器，拿 Tomcat 来说，人家给你提供了线程池参数调整的相关配置，这么一大坨配置，你得用起来啊：

tomcat.apache.org/tomcat-9.0-…

再比如 Dubbo 框架，都给你明说了，这些参数属于性能调优的范畴，感觉不对劲了，你先动手调调啊：

你把这些参数调优弄好了，绝对比你直接怼个线程池在业务代码中，效果好的多。

甚至，你在业务代码中加入一个线程池之后，反而会被“反噬”。

比如，你 duang 的一下怼个线程池在这里，我们先只看 web 容器和业务代码对应的部分：

由于你的业务代码中有线程池的存在，所以当接受到一个 web 请求之后，立马就把请求转发到了业务线程池中，由线程池中的线程来处理本次请求，从而释放了 web 请求对应的线程，该线程又可以里面去处理其他请求。

这样来看，你的吞吐量确实上去了。

在前端来看，非常的 nice，请求立马得到了响应。

但是，你考虑过下游吗？

你的吞吐量上涨了，下游同一时间处理的请求就变多了。如果下游跟不上处理，顶不住了，直接就是崩给你看怎么办？

而且下游不只是你一个调用方，由于你调用的太猛，导致其他调用方的请求响应不过来，是会引起连锁反应的。

所以，这种场景下，为了异步怼个线程池放着，我觉得还不如用消息队列来实现异步化，顶天了也就是消息堆积嘛，总比服务崩了好，这样更加稳妥。

或者至少和下游勾兑一下，问问我们这边吞吐量上升，你们扛得住不。

有的小伙伴看到这里可能就会产生一个疑问了：歪师傅，你这个讲得怎么和我背的八股文不一样啊？

巧了，你背过的八股文我也背过，现在我们来温习一下我们背过的八股文。

什么时候使用线程池呢？

比如一个请求要经过若干个服务获取数据，且这些数据没有先后依赖，最终需要把这些数据组合起来，一并返回，这样经典的场景：

用户点商品详情，你要等半天才展示给用户，那用户肯定骂骂咧咧的久走了。

这个时候，八股文上是怎么说的：用线程池来把串行的动作改成并行。

这个场景也是增加了服务 A 的吞吐量，但是用线程池就是非常正确的，没有任何毛病。

但是你想想，我们最开始的这个案例，是这个场景吗？

我们最开始的案例是想要在业务逻辑中增加一个线程池，对着一个下游服务就是一顿猛攻，不是所谓的串行改并行，而是用更多的线程，带来更多的串行。

这已经不是一个概念了。

还有一种场景下，使用线程池也是合理的。

比如你有一个定时任务，要从数据库中捞出状态为初始化的数据，然后去调用另外一个服务的接口查询数据的最终状态。

如果你的业务代码是这样的：

//获取订单状态为初始化的数据(0:初始化 1:处理中 2:成功 3:失败)

//select * from order where order_status=0;

ArrayList initOrderInfoList = queryInitOrderInfoList();

//循环处理这批数据

for(OrderInfo orderInfo : initOrderInfoList){

    //捕获异常以免一条数据错误导致循环结束

    try{

        //发起rpc调用

        String orderStatus = queryOrderStatus(orderInfo.getOrderId);

        //更新订单状态

        updateOrderInfo(orderInfo.getOrderId,orderStatus);  

    } catch (Exception e){

        //打印异常

    }

}

虽然你框架中使用了线程池，但是你就是在一个 for 循环中不停的去调用下游服务查询数据状态，是一条数据一条数据的进行处理，所以其实同一时间，只是使用了框架的线程池中的一个线程。

为了更加快速的处理完这批数据，这个时候，你就可以怼一个线程池放在 for 循环里面了：

//循环处理这批数据

for(OrderInfo orderInfo : initOrderInfoList){

    //使用线程池

    executor.execute(() -> {

        //捕获异常以免一条数据错误导致循环结束

        try {

            //发起rpc调用

            String orderStatus = queryOrderStatus(orderInfo.getOrderId);

            //更新订单状态

            updateOrderInfo(orderInfo.getOrderId, orderStatus);

        } catch (Exception e) {

            //打印异常

        }

    });

}

需要注意的是，这个线程池的参数怎么去合理的设置，是需要考虑的事情。

同时这个线程池的定位，就类似于 web 容器线程池的定位。

或者这样对比起来看更加清晰一点：

定时任务触发的时候，在发起远程接口调用之前，没有线程池，所以我们可以启用一个线程池来加快数据的处理。

而 Http 调用或者 RPC 调用，框架中本来就已经有一个线程池了，而且也给你提供了对应的性能调优参数配置，那么首先考虑的应该是把这个线程池充分利用起来。

如果仅仅是因为异步化之后可以提升服务响应速度，没有达到串行改并行的效果，那么我更加建议使用消息队列。

好了，本文的技术部分就到这里啦。

下面这个环节叫做[荒腔走板]，技术文章后面我偶尔会记录、分享点生活相关的事情，和技术毫无关系。我知道看起来很突兀，但是我喜欢，因为这是一个普通博主的生活气息。

荒腔走板

不知道你看完文章之后，有没有产生一个小疑问：最开始部分的 Demo 似乎用处并不大？

是的，我最开始构思的行文结构是是基于 Demo 在源码中找到关于线程池的部分，从而引出其实有一些我们“看不见的线程池”的存在的。

原本周六我是有一整天的时间来写这篇文章，甚至周五晚上还特意把 Demo 搞定，自己调试了一番，该打的断点全部打上，并写完 Demo 那部分之后，我才去睡觉的，想得是第二天早上起来直接就能用。

按照惯例周六睡个懒觉的，早上 11 点才起床，自己慢条斯理的做了一顿午饭，吃完饭已经是下午 1 点多了。

本来想着在沙发上躺一会，结果一躺就是一整个下午。期间也想过起来写一会文章，坐在电脑前又飞快的躺回到沙发上，就是觉得这个事情索然无味，当下的那一刻就想躺着，然后无意识的刷手机，原本是拿来写文章中关于源码的部分的时间就这样浪费了。

像极了高中时的我，周末带大量作业回家，准备来个悬梁刺股，弯道超车，结果变成了一睡一天，捏紧刹车。

高中的时候，时间浪费了是真的可惜。

现在，不一样了。

荒腔走板这张图片，就是我躺在沙发上的时候，别人问我在干什么时随手拍的一张。

我并不为躺了一下午没有干正事而感到惭愧，浪费了的时间，才是属于自己的时间。

很久以前我看到别人在做一些浪费时间的事情的时候，我心里可能会嘀咕几句，劝人惜时。

这两年我不会了，允许自己做自己，允许别人做别人。

作者：why技术
来源：juejin.cn/post/7297980721590272040

收起阅读 »

8年前端，那就聊聊被裁的感悟吧！！

web

前端开发，8年工作经验，一共呆了2家公司，一个是做积分兑换的广告公司。这是一个让我成长并快乐的公司，并不是因为公司多好，而是遇到了一群快乐的朋友，直到现在还依旧联系着。另一家是做电子签名的独角兽，我人生的至暗时刻就是在这里这里并不是说公司特别不好，而是自己的...

继续阅读 »

前端开发，8年工作经验，一共呆了2家公司，一个是做积分兑换的广告公司。这是一个让我成长并快乐的公司，并不是因为公司多好，而是遇到了一群快乐的朋友，直到现在还依旧联系着。
另一家是做电子签名的独角兽，我人生的至暗时刻就是在这里这里并不是说公司特别不好，而是自己的际遇

我的经历

第一家公司

第一家公司说来也巧，本来是准备入职一家外包的，在杭州和同学吃个饭，接到了面试通知，一看地址就在楼上，上去一共就3轮面试，不到2个小时直接给了offer。有些东西真的就是命中注定

第二家公司

第二家公司我入职以后挖了上家公司诸多墙角，我一共挖了6个前端，2个后端。拯救朋友们于水深火热之中。

我本以为我能开启美好的新生活，结果第二年就传来我父亲重病的噩耗 肺癌晚期，我学习了大量的肺癌知识什么小细胞，非小细胞，基因检测呀等等。。。

可是最后还是没有挽留住他的生命，我记得我俩在最后一次去武汉的时候，睡在一起，他给我说了很多。

他说：治不好就算了，只是没能看到自己的孙子有些可惜罢了。

他说：我这一辈碌碌无为，没给你带来多么优越的条件，结婚、买房、工作都没给到任何帮助，唯一让我感到欣慰的是你那么努力，比我强多了，家里邻居很多都眼馋你呢。
他说：你小孩的名字想好了吗？你媳妇真是个孝顺的孩子，性格也好，心地善良，你要好好对待她。

他说了很多。。。我都快忘了他说了啥了，我不想忘来着，可是可是，想起来就又好难过。

这只是我人生历程的一部分，我把这些讲出来，是为了让大家明白，你现在所经历的困苦其实没有那么严重，人在逆境之中会放大自己的困难，以博得同情。所以现在很多人给我倒苦水的时候，我总有点不屑一顾的感觉，并不是我有多强，我只是觉得都能过去。

在灰暗的时候，工作总是心不在焉，情绪莫名冲动，我和领导吵过架，和ui妹妹撕破脸，导致人家天天投诉我。我leader说我态度极其嚣张，我说你再多说一句，我干死你所以不裁我裁谁。

我的人生感悟

我时常以我爸的角度换位思考，我在得知这个消息后我该咋办？是积极面对，还是放弃治疗？可是所有的都是在假设的前提之下，一切不可为真。只有在其中的才最能明白其中的感受。
那一年我看着他积极想活着的毅力，也看到了他身体日渐消瘦的无奈，无奈之余还要应付各种亲戚的嘘寒问暖。

我现在很能明白《天道》中那段，丁元英说的如果为了孝顺的名声，让父亲痛苦没有尊严地活着，还不如让父亲走了。 的意思了。在他昏迷不醒的时候，大小便失禁的时候，真不如有尊严的走了。

我其实已经预感到自己要被裁，我原本是挺担心的，可是后来想想父亲的话，我总结成一句话圆滑对事，诚以待人。 这句话看上去前后矛盾，无外乎俩个观点。

圆滑对事的意思是：就是要学会嘴甜，事嘛能少干就少干，能干几分是几分，累的是别人，爽的是自己，在规则中寻求最大的自我利益化。

诚以待人的意思是：圆滑归圆滑，不能对谁都圆滑，你得有把事情办的很好的能力，你需要给真正需要的人创造价值，而不是为了给压榨者提供以自我健康为代价的价值。

用现在最流行的词来说就是「佛系」。

什么叫活明白了，通常被理解为不争不抢，得之淡然、失之泰然、顺其自然的一种心理状态。

活明白的人一般知道自己要什么样的生活，他们不世故、不圆滑，坦荡的、磊落的做自己应该做的事儿。他们与社会上潜规则里的不良之风格格不入，却不相互抵触，甚至受到局中人的青睐与欣赏。

活明白的人看着更为洒脱，得不张扬，失不气馁，心态随和、随遇而安。

不过，还有一种活明白的人，不被多数人所接受。他们玩世不恭、好吃懒做，把所有一切交给命运去背锅。这种人极度自我，没有什么可以超越他自己的利益，无法想象这种活法，简直就是在浪费六道轮回的名额。

总之，有的人活明白了，是调整自己的心态，维护社会的稳定和安宁。有的人活明白了，是以自我为中心，一边依赖着社会救济，一边责备社会龌蹉。

所以，活明白的人也分善与恶，同样是一种积极向善，另一种是消极向恶，二者同出而异名。

我对生活的态度

离职的第一个月，便独自一人去了南京，杭州，长沙，武汉，孝感。我见了很多老朋友，听听他们发发牢骚，然后找一些小众的景点完成探险。

在南京看了看中医，在杭州露营看了看日落，在长沙夜爬了岳麓山，在武汉坐了超级大摆锤，在孝感去了无名矿坑并在一个奶奶家蹭了中午饭。

我的感受极其良好，我体验了前所未有生活态度，我热情待人，嘻嘻笑笑，我站在山顶敞怀吹风，在无尽的树林中悠然自得，治愈我不少的失落情绪。我将继续为生活的不易奔波，也将继续热爱生活，还会心怀感恩对待他人，也会圆滑处事事事佛系。

可能能解决你的问题

要不要和家里人说

我屏蔽了家里人，把负面情绪隐藏，避免波及母亲本就脆弱的内心世界，我还骗她说公司今年不挣钱，提前让我们放假，只给基础工资。如果你家境殷实，家庭和睦，我建议大方的说，这样你和父母又多了一个可以聊的话题，不妨和他们多多交流，耐心一些。

裁员，真不是你的问题

请记住，你没有任何问题，你被裁员是公司的损失，你不需要为此担责，你需要做的是让自己更强，不管是心理、身体还是技术，你得让自己变得精彩，别虚度了这如花般的时光。可能你懒，可能也没什么规划，那就想到啥就做啥好了，可能前几次需要鼓足干劲，后面就会发现轻而易举。

如何度过很丧的阶段

沮丧需要一个发泄的出口，可以保持运动习惯，比如日常爬楼梯、跑步等，一场大汗淋漓后，又是一个打满鸡血积极向上的你。

不要总在家待着，要想办法出门，多建立与社会的联系，多和朋友吹吹牛逼，别把脸面看的那么重要，死皮赖脸反而是一种讨人喜欢的性格。

不管环境怎样，希望你始终向前，披荆斩棘

如果你也正在经历这个阶段，希望你放平心态，积极应对

如果你也在人生的至暗时刻，也请不要彷徨，时间总会治愈一切

不妨试试大胆一点，生活给的惊喜也同样不少

我在一个冬天的夜晚写着文字，希望能对你有些帮助

作者：顾昂_
来源：juejin.cn/post/7331657679012380722

收起阅读 »

Electron实现静默打印小票

web

Electron实现静默打印小票静默打印流程 1.渲染进程通知主进程打印 //渲染进程 data是打印需要的数据 window.electron.ipcRenderer.send('handlePrint', data) 2.主进程接收消息,创建打印页面...

继续阅读 »

Electron实现静默打印小票

静默打印流程

1.渲染进程通知主进程打印

//渲染进程 data是打印需要的数据

window.electron.ipcRenderer.send('handlePrint', data)

2.主进程接收消息,创建打印页面

//main.ts

/* 打印页面 */

let printWindow: BrowserWindow | undefined

/**

 * @Author: yaoyaolei

 * @Date: 2024-06-07 09:27:22

 * @LastEditors: yaoyaolei

 * @description: 创建打印页面

 */

const createPrintWindow = () => {

  return new Promise<void>((resolve) => {

    printWindow = new BrowserWindow({

      ...BASE_WINDOW_CONFIG,

      title: 'printWindow',

      webPreferences: {

        preload: join(__dirname, '../preload/index.js'),

        sandbox: false,

        nodeIntegration: true,

        contextIsolation: false

      }

    })



    printWindow.on('ready-to-show', () => {

      //打印页面创建完成后不需要显示,测试时可以调用show查看页面样式(下面有我处理的样式图片)

      // printWindow?.show()

      resolve()

    })



    printWindow.webContents.setWindowOpenHandler((details: { url: string }) => {

      shell.openExternal(details.url)

      return { action: 'deny' }

    })



    if (is.dev && process.env['ELECTRON_RENDERER_URL']) {

      printWindow.loadURL(`${process.env['ELECTRON_RENDERER_URL']}/print.html`)

    } else {

      printWindow.loadFile(join(__dirname, `../renderer/print.html`))

    }

  })

}



ipcMain.on('handlePrint', (_, obj) => {

   //主进程接受渲染进程消息,向打印页面传递数据

  if (printWindow) {

    printWindow!.webContents.send('data', obj)

  } else {

    createPrintWindow().then(() => {

      printWindow!.webContents.send('data', obj)

    })

  }

})

3.打印页面接收消息，拿到数据渲染页面完成后通知主进程开始打印

<!doctype html>

<html>

<head>

  <meta charset="UTF-8" />

  <title>打印</title>

  <style>

  </style>

</head>



<body>



</body>

<script>

  window.electron.ipcRenderer.on('data', (_, obj) => {

  //这里是接受的消息,处理完成后将html片段放在body里面完成后就可以开始打印了

  //样式可以写在style里,也可以内联

    console.log('event, data: ', obj);

  //这里自由发挥

    document.body.innerHTML = '处理的数据'

  //通知主进程开始打印

    window.electron.ipcRenderer.send('startPrint')

  })

</script>

</html>

这个是我处理完的数据样式,这个就是print.html

4,5.主进程接收消息开始打印,并且通知渲染进程打印状态

ipcMain.on('startPrint', () => {

  printWindow!.webContents.print(

    {

      silent: true,

      margins: { marginType: 'none' }

    },

    (success) => {

      //通知渲染进程打印状态

      if (success) {

        mainWindow.webContents.send('printStatus', 'success')

      } else {

        mainWindow.webContents.send('printStatus', 'error')

      }

    }

  )

})

完毕~

作者：彷徨的耗子
来源：juejin.cn/post/7377645747448365091

收起阅读 »

几行代码，优雅的避免接口重复请求！同事都说好！

web

背景简介我们日常开发中，经常会遇到点击一个按钮或者进行搜索时，请求接口的需求。如果我们不做优化，连续点击按钮或者进行搜索，接口会重复请求。首先，这会导致性能浪费！最重要的，如果接口响应比较慢，此时，我们在做其他操作会有一系列bug！那么，我们该如...

继续阅读 »

背景简介

我们日常开发中，经常会遇到点击一个按钮或者进行搜索时，请求接口的需求。

如果我们不做优化，连续点击按钮或者进行搜索，接口会重复请求。

首先，这会导致性能浪费！最重要的，如果接口响应比较慢，此时，我们在做其他操作会有一系列bug！

那么，我们该如何规避这种问题呢？

如何避免接口重复请求

防抖节流方式（不推荐）

使用防抖节流方式避免重复操作是前端的老传统了，不多介绍了

防抖实现

<template>

  <div>

    <button @click="debouncedFetchData">请求</button>

  </div>

</template>

<script setup>

import { ref } from 'vue';

import axios from 'axios';



const timeoutId = ref(null);



function debounce(fn, delay) {

  return function(...args) {

    if (timeoutId.value) clearTimeout(timeoutId.value);

    timeoutId.value = setTimeout(() => {

      fn(...args);

    }, delay);

  };

}



function fetchData() {

  axios.get('http://api/gcshi)  // 使用示例API

    .then(response => {

      console.log(response.data);

    })

}



const debouncedFetchData = debounce(fetchData, 300);

</script>

防抖（Debounce） ：

在setup函数中，定义了timeoutId用于存储定时器ID。

debounce函数创建了一个闭包，清除之前的定时器并设置新的定时器，只有在延迟时间内没有新调用时才执行fetchData。

debouncedFetchData是防抖后的函数，在按钮点击时调用。

节流实现

<template>

  <div>

    <button @click="throttledFetchData">请求</button>

  </div>

</template>

<script setup>

import { ref } from 'vue';

import axios from 'axios';



const lastCall = ref(0);



function throttle(fn, delay) {

  return function(...args) {

    const now = new Date().getTime();

    if (now - lastCall.value < delay) return;

    lastCall.value = now;

    fn(...args);

  };

}



function fetchData() {

  axios.get('http://api/gcshi')  //

    .then(response => {

      console.log(response.data);

    })

}



const throttledFetchData = throttle(fetchData, 1000);

</script>

节流（Throttle） ：

在setup函数中，定义了lastCall用于存储上次调用的时间戳。

throttle函数创建了一个闭包，检查当前时间与上次调用时间的差值，只有大于设定的延迟时间时才执行fetchData。

throttledFetchData是节流后的函数，在按钮点击时调用。

节流防抖这种方式感觉用在这里不是很丝滑，代码成本也比较高，因此，很不推荐！

请求锁定（加laoding状态）

请求锁定非常好理解，设置一个laoding状态，如果第一个接口处于laoding中，那么，我们不执行任何逻辑！

<template>

  <div>

    <button @click="fetchData">请求</button>

  </div>

</template>



<script setup>

import { ref } from 'vue';

import axios from 'axios';



const laoding = ref(false);



function fetchData() {

  // 接口请求中，直接返回，避免重复请求

  if(laoding.value) return

  laoding.value = true

  axios.get('http://api/gcshi')  //

    .then(response => {

      laoding.value = fasle

    })

}



const throttledFetchData = throttle(fetchData, 1000);

</script>

这种方式简单粗暴，十分好用！

但是也有弊端，比如我搜索A后，接口请求中；但我此时突然想搜B，就不会生效了，因为请求A还没响应！

因此，请求锁定这种方式无法取消原先的请求，只能等待一个请求执行完才能继续请求。

axios.CancelToken取消重复请求

基本用法

axios其实内置了一个取消重复请求的方法：axios.CancelToken，我们可以利用axios.CancelToken来取消重复的请求，爆好用！

首先，我们要知道，aixos有一个config的配置项，取消请求就是在这里面配置的。

<template>

  <div>

    <button @click="fetchData">请求</button>

  </div>

</template>



<script setup>

import { ref } from 'vue';

import axios from 'axios';



let cancelTokenSource = null;





function fetchData() {

  if (cancelTokenSource) {

    cancelTokenSource.cancel('取消上次请求');

    cancelTokenSource = null;

  }

  cancelTokenSource = axios.CancelToken.source();

  

  axios.get('http://api/gcshi',{cancelToken: cancelTokenSource.token})  //

    .then(response => {

      laoding.value = fasle

    })

}



</script>

我们测试下，如下图：可以看到，重复的请求会直接被终止掉！

CancelToken官网示例

官网使用方法传送门：http://www.axios-http.cn/docs/cancel…

const CancelToken = axios.CancelToken;

const source = CancelToken.source();



axios.get('/user/12345', {

  cancelToken: source.token

}).catch(function (thrown) {

  if (axios.isCancel(thrown)) {

    console.log('Request canceled', thrown.message);

  } else {

    // 处理错误

  }

});



axios.post('/user/12345', {

  name: 'new name'

}, {

  cancelToken: source.token

})



// 取消请求（message 参数是可选的）

source.cancel('Operation canceled by the user.');

也可以通过传递一个 executor 函数到 CancelToken 的构造函数来创建一个 cancel token：

const CancelToken = axios.CancelToken;

let cancel;



axios.get('/user/12345', {

  cancelToken: new CancelToken(function executor(c) {

    // executor 函数接收一个 cancel 函数作为参数

    cancel = c;

  })

});



// 取消请求

cancel();

注意: 可以使用同一个 cancel token 或 signal 取消多个请求。

在过渡期间，您可以使用这两种取消 API，即使是针对同一个请求：

const controller = new AbortController();



const CancelToken = axios.CancelToken;

const source = CancelToken.source();



axios.get('/user/12345', {

  cancelToken: source.token,

  signal: controller.signal

}).catch(function (thrown) {

  if (axios.isCancel(thrown)) {

    console.log('Request canceled', thrown.message);

  } else {

    // 处理错误

  }

});



axios.post('/user/12345', {

  name: 'new name'

}, {

  cancelToken: source.token

})



// 取消请求 (message 参数是可选的)

source.cancel('Operation canceled by the user.');

// 或

controller.abort(); // 不支持 message 参数

作者：石小石Orz
来源：juejin.cn/post/7380185173689204746

收起阅读 »

Vite 为何短短几年内变成这样？

web

给前端以福利，给编程以复利。大家好，我是大家的林语冰。 00. 观前须知在 Web 开发领域，Vite 如今已如雷贯耳。自 2020 年 4 月发布以来，Vite 的人气蒸蒸日上。目前 Vite 在 GitHub 上的收藏数量已超过 64k，每周下载量超过...

继续阅读 »

给前端以福利，给编程以复利。大家好，我是大家的林语冰。

00. 观前须知

在 Web 开发领域，Vite 如今已如雷贯耳。

自 2020 年 4 月发布以来，Vite 的人气蒸蒸日上。目前 Vite 在 GitHub 上的收藏数量已超过 64k，每周下载量超过 1200 万次，现在为 Nuxt、Remix、Astro 等大多数开源框架提供支持。

尽管众口嚣嚣，我们意识到许多开发者可能仍然不熟悉 Vite 是什么鬼物，也不熟悉 Vite 在推动现代 Web 框架和工具的开发中扮演的重要角色。

在本文中，我们将科普 Vite 的知识储备，以及 Vite 如何在短短几年后发展成为现代 Web 的重量级角色。

免责声明

本文属于是语冰的直男翻译了属于是，略有删改，仅供粉丝参考。英文原味版请传送 What is Vite (and why is it so popular)?。

01. Vite 是什么鬼物？

Vite 的发音为 /vit/，在法语中是“快速”或“迅捷”的意思，不得不说 Vite 名副其实。

简而言之，Vite 是一种现代 JS 构建工具，为常见 Web 模式提供开箱即用的支持和构建优化，兼具 rollup 的自由度和成熟度。

Vite 还与 esbuild 和原生 ES 模块强强联手，实现快速无打包开发服务器。

Vite 是由“Vue 之父”尤雨溪（Evan You）构思出来的，旨在通过减少开发者在启动开发服务器和处理文件编辑后重载时遭遇的性能瓶颈，简化打包过程。

02. Vite 的核心特性

运行 Vite 时，你会注意到的第一个区别在于，开发服务器会即时启动。

这是因为，Vite 采用按需方法将你的应用程序提供给浏览器。Vite 不会首先打包整个源码，而是响应浏览器请求，将你编写的模块即时转换为浏览器可以理解的原生 ESM 模块。

Vite 为 TS、PostCSS、CSS 预处理器等提供开箱即用的支持，且可以通过不断增长的插件生态系统进行扩展，支持所有你喜欢的框架和工具。

每当你在开发期间更改项目中的任意文件时，Vite 都会使用应用程序的模块图，只热重载受影响的模块（HMR）。这允许开发者预览他们的更改，及其对应用程序的影响。

Vite 的 HMR 速度惊人，可以让编辑器自动保存，并获得类似于在浏览器开发工具中修改 CSS 时的反馈循环。

Vite 还执行 依赖预构建（dependency pre-bundling）。在开发过程中，Vite 使用 esbuild 来打包你的依赖并缓存，加快未来服务器的启动速度。

此优化步骤还有助于加快 lodash 等导出许多迷你模块的依赖的加载时间，因为浏览器只加载每个依赖的代码块（chunk）。这还允许 Vite 在依赖中支持 CJS 和 UMD 代码，因为它们被打包到原生 ESM 模块中。

当你准备好部署时，Vite 将使用优化的 rollup 设置来构建你的应用程序。Vite 会执行 CSS 代码分割，添加预加载指令，并优化异步块的加载，无需任何配置。

Vite 提供了一个通用的 rollup 兼容插件 API，适用于开发和生产，使你可以更轻松地扩展和自定义构建过程。

03. Vite 的优势

使用 Vite 有若干主要优势，包括但不限于：

03-1. 开源且独立

Vite 由开源开发者社区“用爱发电”，由来自不同背景的开发者团队领导，Vite 核心仓库最近贡献者数量已突破 900 人。

Vite 得到积极的开发和维护，不断实现新功能并解决错误。

03-2. 本地敏捷开发

开发体验是 Vite 的核心，每次点击保存时，你都能感受到延迟。我们常常认为重载速度是理所当然的。

但随着您的应用程序增长，且重载速度逐渐停止，你将感恩 Vite 几乎能够保持瞬间重载，而无论应用程序大小如何。

03-3. 广泛的生态系统支持

Vite 的方案人气爆棚，大多数框架和工具都默认使用 Vite 或拥有一流的支持。通过选择使用 Vite 作为构建工具，这些项目维护者可以在它们之间共享一个统一基建，且随着时间的推移共同改良 Vite。

因此，它们可以花更多的时间开发用户需要的功能，而减少重新造轮子的时间。

03-4. 易于扩展

Vite 对 rollup 插件 API 的押注得到了回报。插件允许下游项目共享 Vite 核心提供的功能。

我们有很多高质量的插件可供使用，例如 vite-plugin-pwa 和 vite-imagetools。

03-5. 框架构建难题中的重要角色

Vite 是现代元框架构建的重要组成部分之一，这是一个更大的工具生态系统的一部分。

Volar 提供了在代码编辑器中为 Vue、MDX 和 Astro 等自定义编程语言构建可靠且高性能的编辑体验所需的工具。Volar 允许框架向用户提供悬停信息、诊断和自动补全等功能，并共享 Volar 作为为它们提供支持的通用基建。

另一个很好的例子是 Nitro，它是一个服务器工具包，用于创建功能齐全的 Web 服务器，开箱即用地支持每个主要部署平台。Nitro 是一个与框架无关的库 UnJS 的奇妙集合的一部分。

04. Vite 的未来

在最近的 ViteConf 大会的演讲中，尤雨溪表示，虽然 Vite 取得了巨大进展，但仍面临一些已知的问题和挑战。

Vite 目前使用 rollup 进行生产构建，这比 esbuild 或 Bun 等原生打包器慢得多。

Vite 还尽可能减少开发和生产环境之间的不一致性，但考虑到 rollup 和 esbuild 之间的差异，某些不一致性无法避免。

尤雨溪现在领导一个新团队开发 rolldown，这是一个基于 Rust 的 rollup 移植，在 “JS 氧化编译器 OXC”之上构建了最大的兼容性。

这个主意是用 rolldown 替代 Vite 中的 rollup 和 esbuild。Vite 将拥有一个单独基建，兼具 rollup 的自由度和 esbuild 的速度，消除不一致性，使代码库更易于维护，并加快构建时间。

rolldown 目前处于早期阶段，但已经显示出有希望的结果。rolldown 现已开源，rolldown 团队正在寻找贡献者来辅助实现这一愿景。

与此同时，Vite 团队在每个版本中不断改良 Vite。这项工作从上游的为 Vitest 和 Nuxt Dev SSR 提供动力的引擎 vite-node 开始，现已发展成为框架作者对 Vite API 的完整修订版。

新版 Environment API 预计在 Vite 6 中发布，这将是自 Vite 2 发布以来 Vite 最大的变化之一。这将允许在任意数量的环境中通过 Vite 插件管道运行代码，解锁对 worker、RSC 等的一流支持。

Vite 正在开辟一条前进的道路，并迅速成为 JS 生态系统事实上的构建工具。

参考文献

Vite：vitejs.dev

Blog：blog.stackblitz.com/posts/what-…

Rolldown：rolldown.rs

粉丝互动

本期话题是：如何评价人气爆棚的 Vite，你最喜欢或期待 Vite 的哪个功能？你可以在本文下方自由言论，文明科普。

欢迎持续关注“前端俱乐部”，给前端以福利，给编程以复利。

坚持阅读的小伙伴可以给自己点赞！谢谢大家的点赞，掰掰~

作者：前端俱乐部
来源：juejin.cn/post/7368836713965486119

收起阅读 »

封装WebSocket消息推送，干翻Ajax轮询方式

web

建议可以提前先看下之前两篇文章，深度学习！仅仅只会Ajax,那就out了！WebSocket实战解锁实时通信新境界！ WebSocket: 实时通信的魔法快递，让你的网络生活飞跃升级！使用AJAX和WebSocket都可以实现消息推送，但它们在实现方式和...

继续阅读 »

建议可以提前先看下之前两篇文章，深度学习！

仅仅只会Ajax,那就out了！WebSocket实战解锁实时通信新境界！

WebSocket: 实时通信的魔法快递，让你的网络生活飞跃升级！

使用AJAX和WebSocket都可以实现消息推送，但它们在实现方式和适用场景上有所不同。下面是使用这两种技术实现消息推送的简要说明。

AJax实现或WebSocket实现对比

AJAX 实现消息推送

AJAX（Asynchronous JavaScript and XML）允许你在不重新加载整个页面的情况下，与服务器进行数据交换。但是，传统的AJAX并不直接支持实时消息推送，因为它基于请求-响应模式。为了模拟消息推送，你可以使用轮询（polling）或长轮询（long-polling）技术。

轮询（Polling）

轮询是定期向服务器发送请求，以检查是否有新的消息。这种方法简单但效率较低，因为即使在没有新消息的情况下，也会频繁地发送请求。

function pollForMessages() {

    $.ajax({

        url: '/messages', // 假设这是获取消息的API端点

        method: 'GET',

        success: function(data) {

            // 处理接收到的消息

            console.log(data);

            

            // 等待一段时间后再次轮询

            setTimeout(pollForMessages, 5000); // 每5秒轮询一次

        },

        error: function() {

            // 处理请求失败的情况

            setTimeout(pollForMessages, 10000); // 等待更长时间后重试

        }

    });

}



// 开始轮询

pollForMessages();

长轮询（Long-Polling）

长轮询是轮询的一种改进方式。客户端发起一个请求到服务器，服务器会保持这个连接打开直到有新消息到达或超时，然后返回新消息或超时响应。这种方式比简单轮询减少了无效的请求，但仍然存在一定的延迟和资源浪费。

使用长轮询时，通常需要在服务器端有特殊的支持来保持连接直到有数据可以发送。

WebSocket 实现消息推送

WebSocket 提供了一个全双工的通信通道，允许服务器主动向客户端推送消息。一旦建立了WebSocket连接，服务器和客户端就可以随时向对方发送消息，而不需要像AJAX那样频繁地发起请求。

WebSocket 客户端实现

var socket = new WebSocket('ws://your-server-url');



socket.onopen = function(event) {

    // 连接打开后，你可以向服务器发送消息

    socket.send('Hello Server!');

};



socket.onmessage = function(event) {

    // 当收到服务器发来的消息时，触发此事件

    console.log('Received:', event.data);

};



socket.onerror = function(error) {

    // 处理错误

    console.error('WebSocket Error:', error);

};



socket.onclose = function(event) {

    // 连接关闭时触发

    console.log('WebSocket is closed now.');

};

WebSocket 服务器端实现

服务器端实现WebSocket通常依赖于特定的服务器软件或框架，如Node.js的ws库、Java的Spring WebSocket等。这些库或框架提供了处理WebSocket连接的API，你可以在这些连接上发送和接收消息。

在WebSocket服务器端，你可以保存与每个客户端的连接，并在需要时向它们发送消息

下面开始做封装WebSocket的介绍

想象

想象一下，你是一位超级快递员，负责把客户的包裹准确无误地送到指定的地址。这些包裹里装的是WebSocket消息，而你的任务是根据每个包裹上的userid和url信息，找到正确的收件人并将包裹送达。

首先，你需要准备一辆超级快递车（也就是WebSocket连接）。这辆车非常智能，它可以记住多个收件人的地址（url），并且同时为他们运送包裹。但是，每个收件人（userid）只能对应一个地址，这样才不会送错。

当有客户找你寄送包裹时，他们会告诉你收件人的userid和地址url。你会把这些信息记在小本本上，然后告诉超级快递车：“嘿，车车，我们要去这个地方送这个包裹给这个人！”

快递车非常听话，它会立即启动并前往指定的地址。一旦到达，它就会静静地等待，直到有包裹需要送出。

当你需要发送消息时，就像把包裹放进快递车里一样简单。你只需告诉快递车：“给这个userid的人送这个包裹！”快递车就会准确无误地将包裹送达给指定的收件人。

如果收件人回复了消息，快递车就像个贴心小助手一样，会第一时间把回信拿给你。你可以轻松地查看并处理这些回信。

这样一来，你就不再需要亲自跑腿送包裹了，超级快递车会帮你搞定一切。你只需要告诉它去哪里、送给谁，然后坐等好消息就行啦！

WebSocketMessenger（快递服务公司） ：
- 负责建立和维护WebSocket连接。
- 采用单例模式，确保同一时间只有一个实例在运行。
- 存储收件人（recipient）和地址（address）信息。
- 提供发送消息（send_message）的方法。

快递员（WebSocket连接实例） ：
- 由WebSocketMessenger创建和管理。
- 负责实际的消息传递工作。
- 知道如何与指定的收件人通信（通过地址）。

客户（发送消息的人） ：
- 使用WebSocketMessenger的服务来发送消息。
- 提供收件人信息和消息内容。

收件人（接收消息的人） ：
- 在WebSocket连接的另一端，接收来自WebSocketMessenger传递的消息。

这些角色通过WebSocket连接进行交互，实现了消息的发送和接收。WebSocketMessenger作为服务提供者，管理着快递员（WebSocket连接实例），而客户和收件人则是服务的使用者。

代码层面

服务node代码可以看上篇文章：
仅仅只会Ajax,那就out了！WebSocket实战解锁实时通信新境界！

// WebSocketMessenger（快递服务公司）

class WebSocketManager {

  constructor(url = null, userId = null, receiveMessageCallback = null) {

    this.socket = null // WebSocket 对象

    this.sendTimeObj = null // 发送信息给服务端的重复调用的时间定时器

    this.reconnectTimeObj = null // 尝试链接的宏观定时器

    this.reconnectTimeDistance = 5000 // 重连间隔，单位：毫秒

    this.maxReconnectAttempts = 10 // 最大重连尝试次数

    this.reconnectAttempts = 0 // 当前重连尝试次数

    this.id = userId //用户ID（业务逻辑，根据自己业务需求调整）

    this.url = url // WebSocket 连接地址

    this.receiveMessageCallback = receiveMessageCallback // 接收消息回调函数

  }



  /**

   * 开启WebSocket

   */

  async start() {

    if (this.url && this.id) {

      // 连接WebSocket

      this.connectWebSocket()

    } else {

      console.error('WebSocket erros: 请传入连接地址和用户id')

    }

  }



  /**

   * 创建WebSocket连接, 超级快递车

   */

  connectWebSocket() {

    // 通过id生成唯一值（服务端要求，具体根据自己业务去调整）

    let id = `${this.id}-${Math.random()}`

    // 创建 WebSocket 对象

    this.socket = new WebSocket(this.url, id) // 快递员（WebSocket连接实例



    // 处理连接打开事件

    this.socket.onopen = (event) => {

      // 给服务端发送第一条反馈信息

      this.startSendServe()

    }



    // 处理接收到消息事件

    this.socket.onmessage = (event) => {

      this.receiveMessage(event)

    }



    // 处理连接关闭事件

    this.socket.onclose = (event) => {

      // 清除定时器

      clearTimeout(this.sendTimeObj)

      clearTimeout(this.reconnectTimeObj)

      // 尝试重连

      if (this.reconnectAttempts < this.maxReconnectAttempts) {

        this.reconnectAttempts++

        console.log('重试链接次数：'+ this.reconnectAttempts)

        this.reconnectTimeObj = setTimeout(() => {

          this.connectWebSocket()

        }, this.reconnectTimeDistance)

      } else {

        // 重置重连次数

        this.reconnectAttempts = 0

        console.error(

          'WebSocketManager erros: Max reconnect attempts reached. Unable to reconnect.'

        )

      }

    }



    // 处理 WebSocket 错误事件

    this.socket.onerror = (event) => {

      console.error('WebSocketManager error:', event)

    }

  }



  /**

   * 发送给node的第一条信息

   */

  startSendServe() {



    this.sendMessage('hi I come from client')

  }



  /**

   * 发送消息

   * @param {String} message 消息内容

   */

  sendMessage(message) {

    if (this.socket.readyState === WebSocket.OPEN) {

      this.socket.send(message)

    } else {

      console.error(

        'WebSocketManager error: WebSocket connection is not open. Unable to send message.'

      )

    }

  }



  /**

   * 接收到消息

   */

  receiveMessage(event) {

    // 根据业务自行处理

    console.log('receiveMessage:', event.data)

    this.receiveMessageCallback && this.receiveMessageCallback(event.data)

  }



  /**

   * 关闭连接

   */

  closeWebSocket() {

    this.socket.close()

    // 清除定时器 重置重连次数

    clearTimeout(this.sendTimeObj)

    clearTimeout(this.reconnectTimeObj)

    this.reconnectAttempts = 0

  }

}

代码解读

该类用于管理和控制WebSocket连接，包括连接建立、消息接收、重连机制等。下面是对代码的详细解读：

构造函数 `constructor`

url: WebSocket的连接地址。

userId: 用户的ID，用于业务逻辑处理。

receiveMessageCallback: 接收消息时的回调函数。

初始化了一些成员变量，包括socket（WebSocket对象）、定时器对象（sendTimeObj和reconnectTimeObj）、重连间隔和尝试次数等。

`start` 方法

检查url和userId是否存在，若存在则调用connectWebSocket方法建立WebSocket连接。

`connectWebSocket` 方法

生成一个基于用户ID和随机数的唯一值作为WebSocket的子协议（或协议片段）。

创建新的WebSocket连接。

设置了WebSocket的onopen、onmessage、onclose和onerror事件处理器。

事件处理器

onopen: 当WebSocket连接打开时触发，开始发送消息给服务端（通过startSendServe方法，该方法在代码片段中未给出）。

onmessage: 当接收到服务端发送的消息时触发，调用receiveMessage方法处理消息。

onclose: 当WebSocket连接关闭时触发，首先清除相关定时器，然后尝试重连。如果重连次数未达到最大限制，则设置定时器在一段时间后重新调用connectWebSocket进行重连；如果达到最大重连次数，则重置重连次数并输出错误信息。

onerror: 当WebSocket发生错误时触发，输出错误信息。
当服务端断开后开始重连

这里设置重连10次后断开

`receiveMessage` 方法

该方法应该是用来处理从服务端接收到的消息，具体实现取决于业务逻辑。根据传入的回调函数receiveMessageCallback，可以对接收到的消息进行相应处理

使用Demo

index.html

<head>

    <meta charset="UTF-8">

    <meta http-equiv="X-UA-Compatible" content="IE=edge">

    <meta name="viewport" content="width=device-width, initial-scale=1.0">

    <title>Document</title>

    <script src="./webSocketManager.js"></script>

    <script>

        // const WebSocketManager = require('./webSocketManager.js')

        console.log(WebSocketManager)

        /**

         * 接收消息回调

         */

        const receiveMessage = (res)=>{

            console.log('接收消息回调：',res)

        }

        const socketManager = new WebSocketManager('ws://localhost:3000', 'userid292992', receiveMessage)

        socketManager.start()



    </script>

</head>

导入模块即可使用

总结：

相对完善的WebSocket管理器，能够处理连接建立、消息接收和重连等常见场景。但需要注意的是，具体的业务逻辑和错误处理可能需要根据实际情况进行进一步的完善和优化

作者：梦幻星辰吧
来源：juejin.cn/post/7380222254196326412

收起阅读 »

全局异常统一处理很好，但建议你谨慎使用

Java

思考，输出，沉淀。用通俗的语言陈述技术，让自己和他人都有所收获。作者：毅航😜 在SpringBoot应用开发中，利用@ControllerAdvice 结合 @ExceptionHandler来实现对后端服务的统一异常管理似乎已经成为了开发者约定俗成的规...

继续阅读 »

思考，输出，沉淀。用通俗的语言陈述技术，让自己和他人都有所收获。

作者：毅航😜

在SpringBoot应用开发中，利用@ControllerAdvice 结合 @ExceptionHandler来实现对后端服务的统一异常管理似乎已经成为了开发者约定俗成的规范了，为此网上也有很多文章来阐述如何更加优雅的来实现统一异常管理，但这样做真的好吗?

前言

在SpringBoot中的全局统一异常管理通常是指利用@ControllerAdvice 结合 @ExceptionHandler来自定义一个全局的异常处理器，从而避免了在程序中频繁写书写try-catch来对异常进行处理。但结合笔者最近惨痛debug旧有项目的经历来看，笔者不推荐这样去做。

在讨论之前我们不妨先来看看实际开发中都有哪些地方可能出现的异常。

全局异常所带来的困惑

目前，大部分应用在开发时，通常会将代码划分为控制层，服务层，数据访问层三层结构，每个模块负责自己独立的逻辑。简单来看，控制层主要作用在于对外暴露 ur1访问地址，并将前台的处理请求委托给服务层来处理;而对于服务层来说其主要是业务逻辑处理的地方，以登录请求为例，用户名、密码的校验通常会放在服务层来处理;数据访问层则主要用于对数据库进行访问。如下这张图直观的反映了三层架构下各个模块所肩负的责任。

知晓了软件开发过程中的分层架构模式后。我们再来看每个模块可能产生的异常信息。其中：

控制层主要用于处理实现前后端交互逻辑，其主要负责信息收禁、参数校验等，抛出的异常也多是参数校验、请求服务异常等异常信息。

服务层主要用于处理业务逻辑，以及各种外部服务调用、访问数据作、缓存处理、消息处理等处理操作，这部分可能抛出的逻辑就非常多了。例如，数据库访问异常、服务调用异常等问题。

数据访问层则主要负责数据访问实现，其一般没有业务逻辑。由于目前持久层使用技术通常为Mybatis，所以这一层抛出的异常多是Mybatis框架内部所抛出的异常。

不难发现，其中每一层所抛出的异常类型有着很大的差异。而我们在使用全局异常管理时，通常使用如下
代码逻辑：



@ControllerAdvice

public class GlobalExceptionHandler {



    @ExceptionHandler(Exception.class)

    public ResponseEntity<String> handleGlobalException(Exception ex) {

        // 在这里实现异常处理逻辑

       log.error(ex.getMessage());//在控制台打印错误信息

       return Result.error(ex.getMessage());

    }

}

即我们通过在ExceptionHandler执行捕获异常为Exception来尽可能捕获业务中可能遇到的各种异常，相信网上已经有很多博主都在不断讲授这样的写法。

但这样做真的好吗？在笔者最近接手的旧项目中，当后端无法处理前端请求后会返回如下信息：

{

   "message": “服务器异常”,

   "code":602

}

而后台服务通常会打印出如下信息：

（注：此处仅为展示，真实环境出现的异常远比此复杂）

不难发现，通过网上所盛传全局异常处理逻辑，我根本不知道问题出在哪里。我只知道当前程序出现异常，且异常信息为/ by zero。除此之外我无法得到任何有用的信息。

此外，通过在@ExceptionHandler配置Exception.class使得程序可以捕获多种异常信息，但这样粗粒度做法所导致的直接问题就是无法精确的定位异常问题发生所在地，极大的提升了问题定位的难度。以笔者项目同事debug经历来看，当项目无法正常运行时，组内的程序员通常会通过打日志的方法来一行一行定位问题所在。

破解之道

其实造成这样调试困难得本质原因在于全局异常机制的滥用，如下这张图真实的反映了引入全局异常机制后，异常的处理逻辑。

不难发现，当引入全局异常处理后，所有的异常信息都会交由RestExceptionHandler来进行处理。当程序遇到异常时，会将异常信息抛给RestExceptionHandler来处理，并由其定义错误的处理逻辑。

分析到此处，其实你已经发现了。对于全局异常处理逻辑而言，其更适合做异常的兜底工作。即如果当前层出现异常，并且不断上抛的仍然无法解决的话，不妨通过全局统一的异常管理来进行处理，以对这些未处理的异常进行捕获。

此外，异常处理不应该进行像很多博客说的那样，仅是通过e.getMessage打印异常信息就可以了。这对于排查问题没有以一丁点的帮助，可以说是百害而无一利。

对于此，笔者更推荐在打印异常信息时，记录异常以及当前 URL、执行方法等信息以便后期方便问题排查。具体可参考如下代码：



@Slf4j

@RestControllerAdvice

public class GlobExceptionHandler {





    @ExceptionHandler(ArithmeticException.class)//ArithmeticException异常类型通过注解拿到

    public String exceptionHandler(HttpServletRequest request,ArithmeticException exception){

       // 打印详细信息

        log(request,exception);

        return exception.getMessage();



    }





    public void log(HttpServletRequest request, Exception exception) {

        //换行符

        String lineSeparatorStr = System.getProperty("line.separator");



        StringBuilder exStr = new StringBuilder();

        StackTraceElement[] trace = exception.getStackTrace();

        // 获取堆栈信息并输出为打印的形式

        for (StackTraceElement s : trace) {

            exStr.append("\tat " + s + "\r\n");

        }

        //打印error级别的堆栈日志

        log.error("访问地址：" + request.getRequestURL() + ",请求方法：" + request.getMethod() +

                ",远程地址：" + request.getRemoteAddr() + lineSeparatorStr +

                "错误堆栈信息如下:" + exception.toString() + lineSeparatorStr + exStr);

    }

}

当程序发生错误时，其打印的日志信息如下：

不难发现，其完整的打印出了url、方法信息，错误参数、请求地址等信息，极大的降低了线上Bug的排查难度。

总结

技术本身并没有什么对与错之分，只不过有时我们用的方式和时机不对，进而使得本该提效的工具，反而在不断拖垮我们的效率。就如同本文分析的全局异常处理机制一样，其确实可以帮助我们降低try-catch的使用，但错误且不加考虑的乱用只会使得当系统出现问题时，我们只能两眼一抹黑，然后一行一行打日志来定位问题。

最后，对于代码中异常的捕获处理，笔者认为全局异常应该作为异常处理的都兜底操作，而不应该成为异常处理的灵丹妙药！ 此外，全局异常处理过程不应该仅是简单的 e.getMessage()打印异常消息即可，其更应记录更加有助于异常排查的信息例如，方法，请求的url，请求参数等信息。

如果觉文章对你有帮助，不妨点赞+关注，不错过笔者之后的每一次更新！

作者：毅航
来源：juejin.cn/post/7291555600854106147

收起阅读 »

为什么 Android 要采用 Binder 作为 IPC 机制？

Android

Hi 大家好，我是 DHL，大厂程序员，公众号：ByteCode ，在美团、快手、小米工作过。搞过逆向，做过性能优化，研究过系统，擅长鸿蒙、Android、Kotlin、性能优化、职场分享。微信小程序「猿面试」每日分享一道大厂面试题，涉及 Java、And...

继续阅读 »

Hi 大家好，我是 DHL，大厂程序员，公众号：ByteCode ，在美团、快手、小米工作过。搞过逆向，做过性能优化，研究过系统，擅长鸿蒙、Android、Kotlin、性能优化、职场分享。

微信小程序「猿面试」每日分享一道大厂面试题，涉及 Java、Android、鸿蒙和ArkTS、设计模式、算法和数据结构 等内容。

本篇文章主要以面试为主，因此只要记住这些即可。Android 采用 Binder 作为 IPC (进程间通信) 机制的原因主要包括以下几点，

高效性：

Binder 机制通过减少数据拷贝次数来提高 IPC 的效率。在 Binder 机制中，发送方只需要将数据从用户空间拷贝到内核空间一次，接收方可以直接访问内核空间中的数据，避免了额外的数据拷贝。

与其他 IPC 机制相比，Binder 更高效。Binder 数据拷贝只需要一次，而管道、消息队列、Socket 都需要 2 次，但共享内存方式一次内存拷贝都不需要；从性能角度看，Binder 性能仅次于共享内存。

对象级别的通信：

与基于消息的通信方式不同，Binder 机制提供了一种面向对象的 IPC 方法。Binder 允许在进程间传递对象引用，开发者可以像调用本地对象一样调用远程对象的方法，而无需关心对象实际所在的进程。这种面向对象的 IPC 方式让编程模型更自然，易于理解和使用。

支持异步通信

除了同步调用外，Binder 还支持异步通信，这对于构建响应式应用尤其重要。通过异步通信，应用可以在等待 Binder 事务完成时继续执行其他任务，提高了应用的响应性和性能。

安全性

Binder 通过使用 UID（用户 ID）和 PID（进程 ID）来验证请求的来源，提供了进程间通信的安全性保障。这意味着每个 Binder 事务都可以精确到发起者，系统可以据此实施安全策略，例如权限检查，从而防止未授权的数据访问或通信。

每个 Binder 通信都有明确的权限控制，可以限制哪些进程可以访问 Binder 服务，从而增强了系统的安全性。

稳定性

与其他 IPC 机制相比，Binder 是基于 C/S 架构的，是指客户端 (Client) 和服务端 (Server) 组成的架构，Client 端有什么需求，直接发送给 Server 端去完成，架构清晰明朗，Server 端与 Client 端相对独立。

而共享内存实现方式复杂，没有客户与服务端之别，需要充分考虑到访问临界资源的并发同步问题，否则可能会出现死锁等问题；

从这稳定性角度看，Binder 架构优越于共享内存

简便性

Binder 为开发者提供了一套易于使用的 API 来进行进程间通信，隐藏了复杂的内部实现。它使得不同应用之间或应用与系统服务之间的数据传递和方法调用变得简单直观。

总之，由于其高效、安全、简便、面向对象等特性，Binder 成为了 Android 系统中进行 IPC 通信的首选机制。这些特性使得 Binder 非常适合移动设备这种资源受限的环境。

作者：程序员DHL
来源：juejin.cn/post/7378321582399602707

收起阅读 »

如何在3天内开发一个鸿蒙app

web

华为鸿蒙操作系统（HarmonyOS）自2.0版本正式上线以来，在短时间内就部署超过了2亿台设备，纵观全球操作系统的发展史，也是十分罕见的。与其他手机操作系统不同，HarmonyOS自诞生之日起，就是一款面向多设备、分布式的万物互联操作系统。“1+8+N”是H...

继续阅读 »

华为鸿蒙操作系统（HarmonyOS）自2.0版本正式上线以来，在短时间内就部署超过了2亿台设备，纵观全球操作系统的发展史，也是十分罕见的。与其他手机操作系统不同，HarmonyOS自诞生之日起，就是一款面向多设备、分布式的万物互联操作系统。“1+8+N”是HarmonyOS打造的全场景战略，其中，“1”是智能手机，“8”是指大屏、音箱、眼镜、手表、车机、耳机、平板电脑和PC“八大行星”。

围绕着关键的八大行星，周边还有合作伙伴开发的N个“卫星”，指的是移动办公、智能家居、运动健康、影音娱乐及智能出行等板块的延伸业务。

一个典型鸿蒙应用的产品设计，必然要包含鸿蒙应用的特色。既然鸿蒙操作系统主张万物互联，那么配合HarmonyOS独立操作系统的推进，咱们开发的鸿蒙App肯定不能像andriod app一样，还是要多联动鸿蒙操作系统上的流量入口，方能对于后续的业务规划起到更好的拓展作用。一些创新的点包括：

多设备支持，即手机、平板、手表甚至是智汇屏都可以支持

分布式数据或文件能力，不同设备中的同一款应用数据应该是实时同步的，且不完全需要后台服务即可实现

支持卡片功能

支持应用流转

支持原子化服务

开发鸿蒙原生App的两种主流方式

1、请鸿蒙原生开发工程师，用鸿蒙ArkTS语言重新写一遍

我们可以看到鸿蒙官方的开发者文档上，有很详细的开发教程及文档，其中划重点的是，其技术语言为ArkTS语言（直接区别于IOS和Andriod的开发语言）。

这个办法是最完美的开发方式，但也是最慢的开发方式。如果按照鸿蒙原生开发的“套路”去一步步开发鸿蒙版App，就好比中国人学外语一般，开发者还得从0开始学习新的技术语言（ArkTS语言），可能时间窗口就错过了...

2、混合App开发思路

混合app开发框架是指能够同时支持原生开发和Web开发的框架，它可以将原生应用和Web应用的优势结合起来，为开发者提供更高效、更便捷的开发体验。

混合app开发框架的概念最早可以追溯到2009年，当时PhoneGap（现为Cordova）框架的发布标志着混合app开发的开始。PhoneGap允许开发者使用HTML、CSS和JavaScript来开发跨平台的移动应用，并通过插件来访问原生设备功能。随后，混合app开发框架得到了快速发展，涌现出了许多流行的框架，如Ionic、React Native、Xamarin等。2016年至今，混合app开发框架趋于成熟，并开始向更细分的方向发展。

有了混合开发框架和技术实践下，让”一端开发，多端部署“的概念执行成为可能。

混合app开发框架通常采用以下两种技术原理：

WebView：使用WebView控件将Web页面嵌入到原生应用中，从而实现跨平台开发。

JavaScript桥：提供JavaScript与原生代码之间的通信桥梁，使得Web代码可以访问原生设备功能。

特性包括以下四点：

跨平台开发：使用一套代码可以开发Android、iOS等多个平台的应用。

快速开发：提供丰富的UI组件和API，可以快速构建应用原型。

性能优化：通过各种技术手段提升应用性能。

原生功能支持：可以访问原生设备功能，提供更好的用户体验。

兼顾跨操作系统 & 跨智能终端的快速应用开发模式

开发应用要快速的话，还有一个隐藏的前提条件就是：面向业务应用场景可以复用，毕竟现在市场需求日新月异，业务流程线上化基本不会做大的调增，新功能的研发面向市场，也希望能够在短周期内能够在全端（至少是手机端的用户全网发放）。但众所周知，如果用操作系统原生语法开发，就会出现研发团队需要维护三套代码，哪怕修改一个功能，也需要三端共同改造，及其麻烦。

小程序技术或者HTML5技术天然的跨端，以及受益于微信小程序生态近几年来的蓬勃发展，小程序应用场景复用且通过“小程序转换工具”（小程序容器技术，如FinClip；或跨端框架，如Flutter、Weex等），将已有微信小程序一键转换成App，并进行用户活跃和留存，加上社交平台应用作为引流，企业可谓低成本（只需有小程序）的将业务覆盖用户整个生命周期，具了解，凡是小程序容器技术，都有将自己SDK适配鸿蒙操作系统的计划（或者说已经适配了）。

3天内开发一个鸿蒙App？

近期在研究FinClip的免费“小程序转换App”工具，结合他们新推出的鸿蒙SDK，发现还挺好用，大致步骤如下：

上传小程序代码包：如果已经有微信小程序应用，那么下载一下他们家的FinClip Studio（IDE开发工具）进行简单的转换。

使用微信登录插件：已经预先调试好的微信登录插件，非常方便，能够在转好的App中，通过一个中间转换的小程序调起微信登录接口，快速跑通业务。

生成App前必要的配置：如App图标、启动闪屏、权限配置等

生成App：配置一下对应IOS或Andriod的证书，然后「一键」生成App

实操下来，这个工具还是挺方便的。当然，其他跨端转换框架应该也是操作便捷，感兴趣的同学都可以试试。

将小程序转换为App，如果小程序容器技术支持鸿蒙NEXT版本，那么，使用已有小程序+转换App的功能，便能快速开发出一套适配兼容鸿蒙NEXT操作系统的App。

小程序转鸿蒙原生app的创新开发方式，为开发者提供了快速、便捷的开发途径，助力开发者高效地将小程序业务迁移至鸿蒙生态，同时也为用户提供了更加丰富、流畅的应用体验。展望未来，随着技术的不断发展和完善，相信将会有更多创新的开发模式涌现，为开发者和用户带来更加便利、高效的开发和使用体验。

作者：Speedoooo
来源：juejin.cn/post/7379521155286843404

收起阅读 »

实现 Springboot 程序加密，禁止 jadx 反编译

Java

背景 toB 的本地化 java 应用程序，通常是部署在客户机器上，为了保护知识产权，我们需要将核心代码（例如 Lience，Billing，Pay 等）进行加密或混淆，防止使用 jadx 等工具轻易反编译。同时，为了更深层的保护程序，也要防止三方依赖细节被窥...

继续阅读 »

背景

toB 的本地化 java 应用程序，通常是部署在客户机器上，为了保护知识产权，我们需要将核心代码（例如 Lience，Billing，Pay 等）进行加密或混淆，防止使用 jadx 等工具轻易反编译。同时，为了更深层的保护程序，也要防止三方依赖细节被窥探；

业界方案

ProGuard
- 简介：开源社区有名的免费混淆工具，相较于字节码加密，对性能基本无影响；
- 优势：打包阶段混淆字节码，各种变量方法名都变成了abcdefg 等等无意义的符号，字节码可被反编译，但几乎无法阅读，通常被 Android App 用来防止逆向；
- 不足1：只能混淆部分代码，打包阶段较为耗时，对于三方包混淆，并没有什么好办法。
- 不足2：混淆后的代码，会影响 arthas 工具的使用，导致排查问题变慢。
- 不足3：配置比较复杂，曾经在我司 T 项目上用过，令人眼花缭乱。
- 不足4：无法加密三方依赖所有信息；

jar-protect
- 简介：一款国人开发的 springboot jar 加密工具；需要配合 javaagent 解密；
- 优势：打包阶段使用 javassist 重写 class 文件；jadx 反编译后看到的都是空方法。反编译后只能看到类信息和方法签名，无法看到具体内容。
- 不足1：使用 DES 方案，对于几百个三方 jar 的场景，加密手段过重，且加密后的不够完整；
- 不足2：类文件放在一个目录（META-INF/.encode/），非常容易类冲突；
- 不足3：无法加密三方依赖所有信息；

GraalVM
- 简介：Oracle GraalVM 提前将 Java 应用程序编译为独立的二进制文件。与在 Java 虚拟机（JVM）上运行的应用程序相比，这些二进制文件更小，启动速度提高了 100 倍，无需预热即可提供峰值性能，并且使用的内存和 CPU 更少，并且无法反编译。
- 不足：无法支持我司业务程序框架。

core-lib/xjar
- 简介：国人开源的，基于 golang 的加密工具。使用 maven 插件加密，启动时 golang 解密；性能影响未知。
- 优势：可对所有 class 文件加密。
- 不足1：加密后 jar 文件体积翻倍；
- 不足2：依赖 golang 编译，依赖 golang 启动；
- 不足3：无法加密三方依赖所有信息；
- 不足4：开源项目，3年未有新提交。

思考：

我们的需求到底是什么？a：保护知识产权。具体手段为：

对本司项目代码进行加密，使其无法被 jadx 工具轻易反编译，

对本司三方依赖进行加密，使其无法窥探我司三方依赖细节；

但上面的几个项目，基本都是围绕着 class 加密(除了GraalVM)，这无法实现我们的第二个需求。

我们的方案

设计目标：

将项目三方依赖 jar 进行加密，使其无法使用 jadx 反编译，但运行时会生成解密后的临时文件。

将项目本身的 class 进行加密，使其无法使用 jadx 反编译运行时解密后的文件。

加密策略要灵活，轻量，对启动速度，包体积，内存消耗，接口性能的影响要控制在 5% 以内；

设计方案：

加密jar时，使用 maven 打包工具，repackage fat jar；将其内部 lib 目录的依赖进行加密；使 jadx 无法反编译；

加密class时，对于核心业务代码，使用 javassist 工具将其重写，清空方法体，重置属性值；

解密jar时，将指定目录的加密包解密到指定目录，并将其放入 springboot classloader classpath 里。

解密class时，agent 配合判断是否是加密 class，如果是，则寻找加密 class 文件，找到后解密，返回解密后的 classBytes。

逻辑如下：

注意点：

javassist 重写方法体时，需要将 lib 里的所有代码都加入 classpool 的 classpath 里。

javassist 加密后的类，需将其放入到当前 lib 的单独目录进行个例，防止类冲突。

agent 解密要轻量，不能影响程序性能；

三方包的加解密重新打包后，jar 顺序发生变化，较小可能会导致类冲突（比如 log4j）。需要在测试环境验证，如果存在冲突，则需要排包。

End

通过以上方案，我们实现了一个极其轻量的 maven 加密，agent 解密插件。他能够将三方包彻底加密，使 jadx 等工具无法反编译，屏蔽我们的三方依赖细节，同时，该插件也可以加密我们的业务 class 代码，使 jadx 无法反编译运行时生成的代码，从而一定程度的保护我们的知识产权；

另外，私有的加密算法，在性能，体积，内存等方便的影响都控制在 5% 以内。

为了防止混淆后的代码影响 arthas 的使用和 bug patch 的应用，我们放弃了混淆方案，只能说是一种权衡与取舍吧。

从软件防破解的角度来理解，通常只能是加大破解的难度，铁了心想要破解的话，就算是 ProGuard 混淆，也无法解决。也许只能用 GraalVM，但不是每一个客户都会用这个。

应用容器化后为什么性能下降这么多？

综合技术讨论

1. 背景随着越来越多的公司拥抱云原生，从原先的单体应用演变为微服务，应用的部署方式也从虚机变为容器化，容器编排组件k8s也成为大多数公司的标配。然而在容器化以后，我们发现应用的性能比原先在虚拟机上表现更差，这是为什么呢？。 2. 压测结果 2.1 容器化之...

继续阅读 »

1. 背景

随着越来越多的公司拥抱云原生，从原先的单体应用演变为微服务，应用的部署方式也从虚机变为容器化，容器编排组件k8s也成为大多数公司的标配。然而在容器化以后，我们发现应用的性能比原先在虚拟机上表现更差，这是为什么呢？。

2. 压测结果

2.1 容器化之前的表现

应用部署在虚拟机下，我们使用wrk工具进行压测，压测结果如下：

从压测结果看， $\color{red}{平均RT为1.68ms，qps为716/s}$ ，我们再来看下机器的资源使用情况，cpu基本已经被打满。

2.2 容器化后的表现

使用wrk工具进行压测，结果如下：

从压测结果看， $\color{red}{平均RT为2.11ms，qps为554/s}$ ，我们再来看下机器的资源使用情况，cpu基本已经被打满。

2.3 性能对比结果

性能对比	虚拟机	容器
RT	1.68ms	2.11ms
QPS	716/s	554/s

总体性能下降：RT（25%）、QPS（29%）

3. 原因分析

3.1 架构差异

由于应用在容器化后整体架构的不同、访问路径的不同，将可能导致应用容器化后性能的下降，于是我们先来分析下两者架构的区别。我们使用k8s作为容器编排基础设施，网络插件使用calico的ipip模式，整体架构如下所示。

这里需要说明，虽然使用calico的ipip模式，由于pod的访问为service的nodePort模式，所以不会走tunl0网卡，而是从eth0经过iptables后，通过路由到calico的calixxx接口，最后到pod。

3.2性能分析

在上面压测结果的图中，我们容器化后，cpu的软中断si使用率明显高于原先虚拟机的si使用率，所以我们使用perf继续分析下热点函数。

为了进一步验证是否是软中断的影响，我们使用perf进一步统计软中断的次数。

我们发现容器化后比原先软中断多了14%，到这里，我们能基本得出结论，应用容器化以后，需要更多的软中断的网络通信导致了性能的下降。

3.3 软中断原因

由于容器化后，容器和宿主机在不同的网络namespace,数据需要在容器的namespace和host namespace之间相互通信,使得不同namespace的两个虚拟设备相互通信的一对设备为veth pair,可以使用ip link命令创建，对应上面架构图中红色框内的两个设备，也就是calico创建的calixxx和容器内的eth0。我们再来看下veth设备发送数据的过程

static netdev_tx_t veth_xmit(struct sk_buff *skb, struct net_device *dev)

{

...

    if (likely(veth_forward_skb(rcv, skb, rq, rcv_xdp)

...

}



static int veth_forward_skb(struct net_device *dev, struct sk_buff *skb,

			    struct veth_rq *rq, bool xdp)

{

	return __dev_forward_skb(dev, skb) ?: xdp ?

		veth_xdp_rx(rq, skb) :

		netif_rx(skb);//中断处理

}





/* Called with irq disabled */

static inline void ____napi_schedule(struct softnet_data *sd,

				     struct napi_struct *napi)

{

	list_add_tail(&napi->poll_list, &sd->poll_list);

  //发起软中断

	__raise_softirq_irqoff(NET_RX_SOFTIRQ);

}

通过虚拟的veth发送数据和真实的物理接口没有区别，都需要完整的走一遍内核协议栈，从代码分析调用链路为veth_xmit -> veth_forward_skb -> netif_rx -> __raise_softirq_irqoff，veth的数据发送接收最后会使用软中断的方式，这也刚好解释了容器化以后为什么会有更多的软中断，也找到了性能下降的原因。

4. 优化策略

原来我们使用calico的ipip模式，它是一种overlay的网络方案，容器和宿主机之间通过veth pair进行通信存在性能损耗，虽然calico可以通过BGP，在三层通过路由的方式实现underlay的网络通信，但还是不能避免veth pari带来的性能损耗，针对性能敏感的应用，那么有没有其他underly的网络方案来保障网络性能呢？那就是macvlan/ipvlan模式，我们以ipvlan为例稍微展开讲讲。

4.1 ipvlan L2 模式

IPvlan和传统Linux网桥隔离的技术方案有些区别，它直接使用linux以太网的接口或子接口相关联，这样使得整个发送路径变短，并且没有软中断的影响，从而性能更优。如下图所示：

上图是ipvlan L2模式的通信模型，可以看出container直接使用host eth0发送数据，可以有效减小发送路径，提升发送性能。

4.2 ipvlan L3 模式

ipvlan L3模式，宿主机充当路由器的角色，实现容器跨网段的访问，如下图所示：

4.3 Cilium

除了使用macvlan/ipvlan提升网络性能外，我们还可以使用Cilium来提升性能，Cilium为云原生提供了网络、可观测性、网络安全等解决方案，同时它是一个高性能的网络CNI插件，高性能的原因是优化了数据发送的路径，减少了iptables开销，如下图所示：

虽然calico也支持ebpf，但是通过benchmark的对比，Cilium性能更好，高性能名副其实，接下来我们来看看官网公布的一些benchmark的数据，我们只取其中一部分来分析，如下图:

无论从QPS和CPU使用率上Cilium都拥有更强的性能。

5. 总结

容器化带来了敏捷、效率、资源利用率的提升、环境的一致性等等优点的同时，也使得整体的系统复杂度提升一个等级，特别是网络问题，容器化使得整个数据发送路径变长，排查难度增大。不过现在很多网络插件也提供了很多可观测性的能力，帮助我们定位问题。

我们还是需要从实际业务场景出发，针对容器化后性能、安全、问题排查难度增大等问题，通过优化架构，增强基础设施建设才能让我们在云原生的路上越走越远。

最后，感谢大家观看，也希望和我讨论云原生过程中遇到的问题。

5. 参考资料

docs.docker.com/network/dri…

cilium.io/blog/2021/0…

作者：云之舞者
来源：juejin.cn/post/7268663683881828413

收起阅读 »

SpringBoot获取不到用户真实IP怎么办

Java

今天周六，Binvin来总结一下上周开发过程中遇到的一个小问题，项目部署后发现服务端无法获取到客户端真实的IP地址，这是怎么回事呢？给我都整懵逼了，经过短暂的思考，我发现了问题的真凶，那就是我们使用了Nginx作的请求转发，这才导致了获取不到客户端真实的IP地...

继续阅读 »

今天周六，Binvin来总结一下上周开发过程中遇到的一个小问题，项目部署后发现服务端无法获取到客户端真实的IP地址，这是怎么回事呢？给我都整懵逼了，经过短暂的思考，我发现了问题的真凶，那就是我们使用了Nginx作的请求转发，这才导致了获取不到客户端真实的IP地址，害，看看我是怎么解决的吧！

问题原因

客户端请求数据时走的是Nginx反向代理，默认情况下客户端的真实IP地址会被其过滤，使得SpringBoot程序无法直接获得真实的客户端IP地址，获取到的都是Nginx的IP地址。

解决方案：

通过更改Nginx配置文件将客户端真实的IP地址加到请求头中，这样就能正常获取到客户端的IP地址了，下面我一步步带你看看如何配置和获取。

修改Nginx配置文件

在需要做请求转发的配置里添加下面的配置

#这个参数设置了HTTP请求头的Host字段，host表示请求的Host头，也就是请求的域名。通过这个设置，Nginx会将请求的Host头信息传递给后端服务。

proxy_set_header Host $host;

#这个参数设置了HTTP请求头的X−Real−IP字段，remote_addr表示客户端的IP地址。通过这个设置，Nginx会将客户端的真实IP地址传递给后端服务

proxy_set_header X-Real-IP $remote_addr;

#这个参数设置了HTTP请求头的 X-Forwarded-For字段，"X-Forwarded-For"是一个标准的HTTP请求头，用于表示HTTP请求经过的代理服务器链路信息，proxy_add_x_forwarded_for表示添加额外的服务器链路信息。

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

修改后我的nginx.conf中的server如下所示

server {

  listen 443 ssl;

  server_name xxx.com;



  ssl_certificate "ssl证书pem文件";

  ssl_certificate_key "ssl证书key文件";

  ssl_session_timeout 5m;

  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

  ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;

  ssl_prefer_server_ciphers on;



  location / {

    root   前端html文件目录;

    index  index.html index.htm;

  }



  error_page   500 502 503 504  /50x.html;

  location = /50x.html {

    root html;

  }

  # 关键在下面这个配置，上面的配置自己根据情况而定就行

  location /hello{

    proxy_pass http://127.0.0.1:8090;

    proxy_set_header Host $host;

    proxy_set_header X-Real-IP $remote_addr; 

    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

  }

}

SpringBoot代码实现

第一种方式：在代码中直接通过X-Forwarded-For获取到真实IP地址

@Slf4j

public class CommonUtil {

    /**

     * <p> 获取当前请求客户端的IP地址 </p>

     *

     * @param request 请求信息

     * @return ip地址

     **/

    public static String getIp(HttpServletRequest request) {

        if (request == null) {

            return null;

        }

        String unknown = "unknown";

        // 使用X-Forwarded-For就能获取到客户端真实IP地址

        String ip = request.getHeader("X-Forwarded-For");

        log.info("X-Forwarded-For:" + ip);

        if (ip == null || ip.length() == 0 || unknown.equalsIgnoreCase(ip)) {

            ip = request.getHeader("Proxy-Client-IP");

            log.info("Proxy-Client-IP:" + ip);

        }

        if (ip == null || ip.length() == 0 || unknown.equalsIgnoreCase(ip)) {

            ip = request.getHeader("WL-Proxy-Client-IP");

            log.info("WL-Proxy-Client-IP:" + ip);

        }

        if (ip == null || ip.length() == 0 || unknown.equalsIgnoreCase(ip)) {

            ip = request.getHeader("HTTP_X_FORWARDED_FOR");

            log.info("HTTP_X_FORWARDED_FOR:" + ip);

        }

        if (ip == null || ip.length() == 0 || unknown.equalsIgnoreCase(ip)) {

            ip = request.getHeader("HTTP_X_FORWARDED");

            log.info("HTTP_X_FORWARDED:" + ip);

        }

        if (ip == null || ip.length() == 0 || unknown.equalsIgnoreCase(ip)) {

            ip = request.getHeader("HTTP_X_CLUSTER_CLIENT_IP");

            log.info("HTTP_X_CLUSTER_CLIENT_IP:" + ip);

        }

        if (ip == null || ip.length() == 0 || unknown.equalsIgnoreCase(ip)) {

            ip = request.getHeader("HTTP_CLIENT_IP");

            log.info("HTTP_CLIENT_IP:" + ip);

        }

        if (ip == null || ip.length() == 0 || unknown.equalsIgnoreCase(ip)) {

            ip = request.getHeader("HTTP_FORWARDED_FOR");

            log.info("HTTP_FORWARDED_FOR:" + ip);

        }

        if (ip == null || ip.length() == 0 || unknown.equalsIgnoreCase(ip)) {

            ip = request.getHeader("HTTP_FORWARDED");

            log.info("HTTP_FORWARDED:" + ip);

        }

        if (ip == null || ip.length() == 0 || unknown.equalsIgnoreCase(ip)) {

            ip = request.getHeader("HTTP_VIA");

            log.info("HTTP_VIA:" + ip);

        }

        if (ip == null || ip.length() == 0 || unknown.equalsIgnoreCase(ip)) {

            ip = request.getHeader("REMOTE_ADDR");

            log.info("REMOTE_ADDR:" + ip);

        }

        if (ip == null || ip.length() == 0 || unknown.equalsIgnoreCase(ip)) {

            ip = request.getRemoteAddr();

            log.info("getRemoteAddr:" + ip);

        }

        return ip;

    }

第二种方式：在application.yml文件中加以下配置，直接通过request.getRemoteAddr()并可以获取到真实IP

server:

  port: 8090

  tomcat:

    #Nginx转发 获取客户端真实IP配置

    remoteip:

      remote-ip-header: X-Real-IP

      protocol-header: X-Forwarded-Proto

作者：rollswang
来源：juejin.cn/post/7266040474321027124

收起阅读 »

小知识分享：控制层尽量别暴露这样的接口，避免横向越权。

Java

前言谈不上是多么厉害的知识，但可能确实有人不清楚或没见过。我还是分享一下，就当一个小知识点。如果知道的，就随便逛逛，不知道的，Get到了记得顺手点个赞哈。正文 1、接口别随便暴露当一个项目的维护周期拉长的时候，不断有新增的需求，如果经手的人也越...

继续阅读 »

前言

谈不上是多么厉害的知识，但可能确实有人不清楚或没见过。

我还是分享一下，就当一个小知识点。

如果知道的，就随便逛逛，不知道的，Get到了记得顺手点个赞哈。

正文

1、接口别随便暴露

当一个项目的维护周期拉长的时候，不断有新增的需求，如果经手的人也越来越多，接口是会肉眼可见增多的。

此时，如果一个团队没有良好的规范和代码审查机制，就会导致许多不安全的接口被暴露出来。

比如下面这种接口：

/**

* 根据ID查询患者信息

*/

@GetMapping("/{id}")

public AjaxResult getById(@PathVariable("id") Long id) {

    PersonInfo personInfo = personInfoService.selectPersonInfoById(id);

    return AjaxResult.success(personInfo);

}

这种接口是我们部门以前审查出来的其中一个，类似这样的接口还有很多。

这些接口都是不同的同事在紧凑的工作任务中写的，慢慢就积累出了一堆。

还有些是为了方便，直接通过代码生成器生成的，而代码生成器是把常用的CRUD接口都给你生成出来，如果研发人员没有责任心，可能就直接不管了，想着以后哪一天也许会用上呢。

别以为这种想法的人少啊，你整个职业生涯很可能就会遇见。

这就导致了，一堆用不上又不安全的接口出现了。

服务过政务机构、企事业单位、医疗等行业的工程师应该就知道，这些单位对于安全性的要求其实挺高的，尤其是这些年，会找专门的信息安全公司做攻防演练。

最近两年，很多省市甚至会自发组织全市的信息安全攻防演练，在当前大环境下这也是符合国情的。

而攻防演练的目的之一就是找系统安全漏洞，这里面就会有一个我本章要讲的典型漏洞，接口的横向越权。

2、什么是横向越权

广义的解释就是，该越权行为允许用户获取他们正常情况下无权访问的信息或执行操作。

如果纯粹从理论上理解，是很抽象的，所以我才把这个案例捞出来，让你一次就懂。

我们再回过头看看上面我贴出来的那段很正常的代码，就是根据id获取用户信息，你一定曾经在一些项目中见过这种接口，提供给前端直接调用，比如用户详情、订单详情，只要是和详情有关的，很可能前端会需要这么一个接口。

那么，问题在这里，我们的id是不是有规则的呢？比如下面这样：

可以看出来，id是自增的，增量是2。其实很多中小企业现在用MySQL都喜欢这样设置自增id，有些会设置增量，有些干脆就默认。

试想一下，我如果知道了id=865的用户信息，我也知道大部分中小企业喜欢用自增id，是不是就等于知道了1-1000000的用户信息，而用户信息可能包含身-份-证、手机号、详细住址等非常敏感的内容。

这就是典型的横向越权之一，我明明只应该拿到id=865这个用户的信息，但是通过非正常的方式，我暴力获取了其他100万个用户信息。

一旦真的发生这样的事故，不管最终结果如何，这家公司基本上就进黑名单了，从此在行业中消失。

3、权限控制不了吗

一定会有人产生疑惑，SpringBoot接口怎么可能直接放出来，一定都是有权限控制的，没有权限是根本不可能访问到的。

我打个比方，如果是后台管理这种，他是有登录的，登录后会产生token，token中是可以包含角色权限的，那么这种是没有问题的。

但如果没有登录操作呢，比如小程序这种，你打开就直接是首页各种信息，前端调接口很可能传递的只有网关层的token，又该如何呢。

尤其是小程序雨后春笋一般涌现的那几年，我曾经打开过很多小程序，都是没什么权限校验的，就是直接点来点去。

直到近几年，这种现象才慢慢消失，很多小程序打开后，会提示你授权登录，比如微信小程序，你一定遇到过打开小程序后让你授权登录的场景，如果不授权登录，你绝对做不了很多操作，这是很多互联网企业的安全意识都加强的结果。

我所在的公司早年刚进入医疗行业就经历过这种事情，为了占坑拿下了很多项目，但缺乏安全意识和管理规范，程序员也是来来走走，你写两个我写两个，导致不少接口都存在安全隐患。

直到被攻防演练攻破，甲方下发整改通知，还要我们写事故报告、原因、解决方案等等一大堆，我们才慌了。

连夜开会讨论出一套基本的安全整改思路，然后开始加班加点做安全改造。

我印象最深的就是其中这个接口横向越权，只传递了网关层的token，而没有细化到个人的权限控制，导致被信息安全公司通过抓包等一些我不了解的技术把token拿到了，然后直接横向获取到了很多用户敏感信息。

当时这个事情闹得很厉害，考虑到只是攻防演练，同时客户方对公司还保留信任，才只要求我们限期整改，否则就直接替换了。

所以，记得以后写接口的时候别只考虑业务逻辑，安全性也是考量之一。

4、如何防范

防范的方式，我归纳了这么几点：

1、不用的接口尽量删掉，这样也避免了多余接口埋下的安全隐患；

2、团队要有安全规范，比如敏感字段加密，引入代码审查机制，缩小安全隐患出现的范围；

3、带登录的终端，除了网关层校验，要精确控制登录用户的角色及权限；

4、不带登录的终端，除了网关层校验，要根据用户的唯一信息，来做授权登录，授权不成功不允许做其他操作，这也是现在比较流行的方式。

我个人理解，第4点和第3点本质一样，因为不带登录，所以要想办法制造登录，而目前比较友好的方式还是一键授权登录，不管是根据openid、手机号等等，总之要找到一个规则，这样省去了用户手动操作登录的时间。

总之，一定要控制用户只能看到属于自己的内容，避免横向越权。

总结

如果写的不好，还望大家原谅，只是分享了曾经工作中发生过的和安全改造有关的事情。

现在的程序员其实了解和接收的知识技术是挺多的，许多人其实都知道这些。

希望不知道的人，能够因为我的文章得到一点点帮助。

最后，大家其实可以去试一试，打开微信小程序，搜索下你们所在城市的某某中心医院，看看这样的医疗小程序打开后是什么样的，是不是有授权登录，或者其他方式来控制权限，搞不好一部分人能遇到有意思的事情。

作者：程序员济癫
来源：juejin.cn/post/7276467933235642405

收起阅读 »

分分钟带你实现视频消息的在线播放和本地播放｜干货教程

环信集成指南

发送视频消息是即时通讯应用中很常见的功能，现在的视频播放场景五花八门，眼瞅快下班，接到产品需求前提条件：实现方法：1、调用下载，下载成功后进行播放处理；EMMessage msg = EMClient.getInstance().chatManager().g...

继续阅读 »

有种需求叫"下班前实现"

发送视频消息是即时通讯应用中很常见的功能，现在的视频播放场景五花八门，眼瞅快下班，接到产品需求

如何快速实现这个需求，好准点下班回家抢显卡，好提升自己的工作效率，你只要熟读本篇文章，分分钟带你实现！

前提条件：

完成环信IM SDK的初始化
（没完成的参考文档：SDK初始化）
实现发送视频消息和接收视频消息
（没实现的参考文档：发送和接收消息）

实现方法：

一、本地播放实现方法

1、调用

EMChatManager#downloadAttachment

下载，下载成功后进行播放处理；

EMMessage msg = EMClient.getInstance().chatManager().getMessage(msgId);
      EMCallBack callback = new EMCallBack() {
                public void onSuccess() {
                    EMLog.e(TAG, "onSuccess" )；
                   //下载成功，进行播放处理
                }

                public void onError(final int error, String message) {
                    EMLog.e(TAG, "offline file transfer error:" + message);
                }

                public void onProgress(final int progress, String status) {
                    EMLog.d(TAG, "Progress: " + progress);
                }
            };
            msg.setMessageStatusCallback(callback);
      EMClient.getInstance().chatManager().downloadAttachment(msg);

2、如果对本地存储的路径有特殊要求：

1）可以先通过

EMFileMessageBody#setlocalUrl

去修改路径；

2）再调用

EMChatManager#downloadAttachment

下载（下载操作可以参考上面）；

二.在线播放实现方法

1、在接收消息监听onMessageReceived里，接收到视频消息；

EMMessageListener msgListener = new EMMessageListener() {
                    // 收到消息，遍历消息队列，解析和显示。
             @Override
             public void onMessageReceived(List<EMMessage> messages) {

              }
     };
    // 注册消息监听
    EMClient.getInstance().chatManager().addMessageListener(msgListener);
    // 解注册消息监听
    EMClient.getInstance().chatManager().removeMessageListener(msgListener);

2、拿到

EMVideoMessageBody#getRemoteUrl

拿到消息的远程服务器存储地址

// 从服务器端获取视频文件。
String imgRemoteUrl = ((EMVideoMessageBody) body).getRemoteUrl();

3、用第三方或者是VideoView进行播放视频（例子里使用的VideoView）；

vidw = (VideoView) findViewById(R.id.viewview);
        vidw.setVideoPath(imgRemoteUrl+"?em-redirect=true");
        vidw.setOnErrorListener(new MediaPlayer.OnErrorListener() {
            @Override
            public boolean onError(MediaPlayer mp, int what, int extra) {
                return true;
            }
        });
  vidw.start();

按照上面的步骤测试，发现还是不能在线播放的朋友，就需要看下，你使用的Appkey需要联系环信商务经理免费开通在线播放功能

另需注意：imgRemoteUrl 需要拼接 ?em-redirect=true，否则也会出现播放不了的情况；

大功告成！快把代码推上去，回家抢显卡！

此教程适用于Android端，其他端兄弟们报一丝，下次一定！

很容易中招的一种索引失效场景，一定要小心

综合技术讨论

快过年，我的线上发布出现故障 “五哥，你在上线吗？”，旁边有一个声音传来。 “啊，怎么了？”。真是要命，在上线发布时候，我最讨厌别人叫我的名字。我慌忙站起来，看向身后，原来是建哥在问我。我慌忙的问，怎么回事。 “DBA 刚才在群里说，Task数据库 cpu...

继续阅读 »

快过年，我的线上发布出现故障

“五哥，你在上线吗？”，旁边有一个声音传来。

“啊，怎么了？”。真是要命，在上线发布时候，我最讨厌别人叫我的名字 。我慌忙站起来，看向身后，原来是建哥在问我。我慌忙的问，怎么回事。

“DBA 刚才在群里说，Task数据库 cpu 负载增加！有大量慢查询”，建哥来我身边，跟我说。

慢慢的，我身边聚集着越来越多的人

“你在上线Task服务吗？改动什么内容了，看看要不要立即回滚？”旁边传来声音。此时，我的心开始怦怦乱跳，手心发痒，紧张不已。

我检查着线上机器的日志，试图证明报警的原因不是出在我这里。

我对着电脑，微微颤抖地回答大家：“我只是升级了基础架构的Jar包，其他内容没有改动啊。”此时我已分不清是谁在跟我说话，只能对着电脑作答……

这时DBA在群里发送了一条SQL，他说这条SQL导致了大量的慢查询。

我突然记起来了，我转过头问林哥：“林哥，你上线了什么内容？”这次林哥有代码的变更，跟我一起上线。我觉得可能是他那边有问题。

果然，林哥看着代码发呆。他嘟囔道：“我添加了索引啊，怎么会有慢查询呢？”原来慢查询的SQL是林哥刚刚添加的，这一刻我心里的石头放下了，问题并不在我，我轻松了许多。

“那我先回滚吧”，幸好我们刚发布了一半，现在回滚还来得及，我尝试回滚机器。此刻我的紧张情绪稍稍平静下来，手也不再发抖。

既然不是我的问题，我可以以吃瓜的心态，暗中观察事态的发展。我心想：真是吓死我了，幸好不是我的错。

然而我也有一些小抱怨：为什么非要和我一起搭车上线，出了事故，还得把我拖进来。

故障发生前的半小时

2年前除夕前的一周，我正准备着过年前的最后一次线上发布，这时候我刚入职两个月，自然而然会被分配一些简单的小活。这次上线的内容是将基础架构的Jar包升级到新版本。一般情况下，这种配套升级工作不会出问题，只需要按部就班上线就行。

“五哥，你是要上线 Task服务吗？”，工位旁的林哥问我，当时我正做着上线前的准备工作。

“对啊，马上要发布，怎么了？”，我转身回复他。

“我这有一个代码变更，跟你搭车一起上线吧，改动内容不太多。已经测试验证过了”，林哥说着，把代码变更内容发给我，简单和我说了下代码变更的内容。我看着改动内容确实不太多，新增了一个SQL查询，于是便答应下来。我重新打包，准备发布上线。

半小时以后，便出现了文章开头的情景。新增加的SQL 导致大量慢查询，数据库险些被打挂。

为什么加了索引，还会出现慢查询呢？

”加了索引，为什么还有慢查询？“，这是大家共同的疑问。

事后分析故障的原因，通过 mysql explain 命令，查看该SQL 确实没有命中索引，从而导致慢查询。

这个SQL 大概长这个样子！我去掉了业务相关的部分。

select * from order_discount_detail where orderId = 1123;

order_discount_detail 在 orderId 这一列上确实加了索引，不应该出现慢查询，乍一看，没有什么问题。我本能的想到了索引失效的几种场景。难道是类型不匹配，导致索引失效？

果不其然， orderId 在数据库中的类型是 varchar 类型，而传参是按照 long 类型传的。

复习一下： 类型转换导致索引失效

类型转换导致索引失效，是很容易犯的错误

因为在某些特殊场景下要对接外部订单，存在订单Id为字符串的情况，所以 orderId被设计成 varchar 字符串类型。然而出问题的场景比较明确，订单id 就是long类型，不可能是字符串类型。

所以林哥，他在使用Mybatis 时，直接使用 long 类型的 orderId字段传参，并且没有意识到两者数据类型不对。

因为测试环境数据量比较小，即使没有命中索引，也不会有很严重的慢查询，并且测试环境请求量比较低，该慢查询SQL 执行次数较少，所以对数据库压力不大，测试阶段一直没有发现性能问题。

直到代码发布到线上环境————数据量和访问量都非常高的环境，差点把数据库打挂。

mybatis 能避免 “类型转换导致索引失效” 的问题吗？

mybatis能自动识别数据库和Java类型不一致的情况吗？如果发现java类型和数据库类型不一致，自动把java 类型转换为数据库类型，就能避免索引失效的情况！

答案是不能。我没找到 mybatis 有这个能力。

mybatis 使用 #{} 占位符，会自动根据参数的 Java 类型填充到 SQL中，同时可以避免SQL注入问题。

例如刚才的SQL 在 mybatis中这样写。

select * from order_discount_detail where orderId = #{orderId};

orderId 是 String 类型，SQL就变为

select * from order_discount_detail where orderId = ‘1123’;

mybatis 完全根据传参的java类型，构建SQL，所以不要认为 mybatis帮你处理好java和数据库的类型差异问题，你需要自己关注这个问题！

再次提醒，"类型转换导致索引失效"的问题，非常容易踩坑。并且很难在测试环境发现性能问题，等到线上再发现问题就晚了，大家一定要小心！小心！

险些背锅

可能有朋友疑问，为什么发布一半时出现慢查询，单机发布阶段不能发现这个问题吗？

之所以没发现这个问题，是因为新增SQL在 Kafka消费逻辑中，由于单机发布机器启动时没有争抢到 kafka 分片，所以没有走到新代码逻辑。

此外也没有遵循降级上线的代码规范，如果上线默认是降级状态，上线过程中就不会有问题。放量阶段可以通过降级开关快速止损，避免回滚机器过程缓慢而导致的长时间故障。

不是我的问题，为什么我也背了锅

因为我在发布阶段没有遵循规范，按照规定的流程应该在单机发布完成后进行引流压测。引流压测是指修改机器的Rpc权重，将Rpc请求集中到新发布的单机上，这样就能提前发现线上问题。

然而由于我偷懒，跳过了单机引流压测。由于发布的第一台机器没有抢占到Kafka分片，因此无法执行新代码逻辑。即使进行了单机引流压测，也无法提前发现故障。虽然如此，但我确实没有遵循发布规范，错在我。

如果上线时没有出现故障，这种不规范的上线流程可能不会受到责备。但如果出现问题，那只能怪我倒霉。在复盘过程中，我的领导抓住了这件事，给予了重点批评。作为刚入职的新人，被指责确实让我感到不舒服。

快要过年了，就因为搭车上线，自己也要承担别人犯错的后果，让我很难受。但是自己确实也有错，当时我的心情复杂而沉重。

两年前的事了，说出来让大家吃个瓜，乐呵一下。如果这瓜还行，东东发财的小手点个赞

作者：五阳
来源：juejin.cn/post/7305572311812636683

收起阅读 »

什么？你设计接口什么都不考虑？

Java

后端接口设计如果让你设计一个接口，你会考虑哪些问题？ 1.接口参数校验接口的入参和返回值都需要进行校验。入参是否不能为空，入参的长度限制是多少，入参的格式限制，如邮箱格式限制返回值是否为空，如果为空的时候是否返回默认值，这个默认值需要和前端协商 ...

继续阅读 »

后端接口设计

如果让你设计一个接口，你会考虑哪些问题？

1.接口参数校验

接口的入参和返回值都需要进行校验。

入参是否不能为空，入参的长度限制是多少，入参的格式限制，如邮箱格式限制

返回值是否为空，如果为空的时候是否返回默认值，这个默认值需要和前端协商

2.接口扩展性

举个例子，比如用户在进行某些操作之后，后端需要进行消息推送，那么是直接针对这个业务流程来开发一个专门为这个业务流程服务的消息推送功能呢？还是说将消息推送整合为一个通用的接口，其他流程都可以进行调用，并非针对特定业务。

这个场景可能光靠说不是很能理解，大家想想策略工厂设计模式，是不是可以根据不同的策略，来选择不同的实现方式呢？再结合上面的这个例子，是否对扩展性有了进一步的理解呢？

3.接口幂等设计

什么是幂等呢？幂等是指多次调用接口不会改变业务状态，可以保证重复调用的结果和单次调用的结果一致

举个例子，在购物商场里面你用手机下单，要买某个商品，你需要去支付，然后你点击了支付，但是因为网速问题，始终没有跳转到

支付界面，于是你又连点了几次支付，那在没有做接口幂等的时候，是不是你点击了多少次支付，我们就需要执行多少次支付操作？

所以接口幂等到的是什么？防止用户多次调用同一个接口

对于查询和删除类型的接口，不论调用多少次，都是不会产生错误的业务逻辑和数据的，因此无需幂等处理

对于新增和修改，例如转账等操作，重复提交就会导致多次转账，这是很严重的，影响业务的接口需要做接口幂等的处理，跟前端约定好一个固定的token接口，先通过用户的id获取全局的token，写入到Redis缓存，请求时带上Token，后端做处理

4.关键接口日志打印

关键的业务代码，是需要打印日志进行监测的，在入参和返回值或者如catch代码块中的位置进行日志打印

方便排查和定位线上问题，划清责任

生产环境是没有办法进行debug的，必须依靠日志查问题，看看到底是出现了什么异常情况

5.核心接口要进行线程池隔离

分类查询啊，首页数据等接口，都有可能使用到线程池，某些普通接口也可能会使用到线程池，如果不做线程池隔离，万一普通接口出现bug把线程池打满了，会导致你的主业务受到影响

6.第三方接口异常重试

如果有场景出现调用第三方接口，或者分布式远程服务的话，需要考虑的问题

异常处理

比如你在调用别人提供的接口的时候，如果出现异常了，是要进行重试还是直接就是当做失败

请求超时

有时候如果对方请求迟迟无响应，难道就一直等着吗？肯定不是这样的，需要设法预估对方接口响应时间，设置一个超时断开的机制，以保护接口，提高接口的可用性，举个例子，你去调用别人对外提供的一个接口，然后你去发http请求，始终响应不回来，此时你又没设置超时机制，最后响应方进程假死，请求一直占着线程不释放，拖垮线程池。

重试机制

如果调用对外的接口失败了或者超时了，是否需要重新尝试调用呢？还是失败了就直接返回失败的数据？

7.接口是否需要采用异步处理

举个例子，比如你实现一个用户注册的接口。用户注册成功时，发个邮件或者短信去通知用户。这个邮件或者发短信，就更适合异步处理。总不能一个通知类的失败，导致注册失败吧。那我们如何进行异步操作呢？可以使用消息队列，就是用户注册成功后，生产者产生一个注册成功的消息，消费者拉到注册成功的消息，就发送通知。

8.接口查询优化，串行优化为并行

假设我们要开发一个网站的首页，我们设计了一个首页数据查询的接口，这个接口需要查用户信息，需要查头部信息，需要查新闻信息

等等之类的，最简单的就是一个一个接口串行调用，那要是想要提高性能，那就采取并行调用的方式，同时查询，而不是阻塞

可以使用CompletableFuture(推荐)或者FutureTask(不推荐)

        Map<Long, List<SubjectLabelBO>> map = new HashMap<>();

        List<CompletableFuture<Map<Long, List<SubjectLabelBO>>>> completableFutureList = 

        categoryBOList.stream().map(category ->

                CompletableFuture.supplyAsync(() -> getLabelBOList(category), labelThreadPool)

        ).collect(Collectors.toList());



        completableFutureList.forEach(future -> {

            try {

                Map<Long, List<SubjectLabelBO>> resultMap = future.get(); //这里会阻塞

                map.putAll(resultMap);

            } catch (Exception e) {

                e.printStackTrace();

            }

        });

        

        public Map<Long, List<SubjectLabelBO>> getLabelBOList(SubjectCategoryBO category) {...}

9.高频接口注意限流

自定义注解 + AOP

@Target(ElementType.METHOD)

@Retention(RetentionPolicy.RUNTIME)

public @interface RateLimiter {

    int value() default 1;

    int durationInSeconds() default 1;

}



@Aspect

@Component

public class RateLimiterAspect {



    private final ConcurrentHashMap<String, RateLimiter> rateLimiters = new ConcurrentHashMap<>();



    @Pointcut("@annotation(RateLimiter)")

    public void rateLimiterPointcut(RateLimiter rateLimiterAnnotation) {

    }



    @Around("rateLimiterPointcut(rateLimiterAnnotation)")

    public Object around(ProceedingJoinPoint joinPoint, RateLimiter rateLimiterAnnotation) throws Throwable {

        int permits = rateLimiterAnnotation.value();

        int durationInSeconds = rateLimiterAnnotation.durationInSeconds();



        // 使用方法签名作为 RateLimiter 的 key

        String key = joinPoint.getSignature().toLongString();

        com.google.common.util.concurrent.RateLimiter rateLimiter = rateLimiters.computeIfAbsent(key, k -> com.google.common.util.concurrent.RateLimiter.create((double) permits / durationInSeconds));



        // 尝试获取令牌，如果获取到则执行方法，否则抛出异常

        if (rateLimiter.tryAcquire()) {

            return joinPoint.proceed();

        } else {

            throw new RuntimeException("Rate limit exceeded.");

        }

    }

}



@RestController

public class ApiController {



    @GetMapping("/api/limited")

    @RateLimiter(value = 10, durationInSeconds = 60) //限制为每分钟 10 次请求

    public String limitedEndpoint() {

        return "This API has a rate limit of 10 requests per minute.";

    }



    @GetMapping("/api/unlimited")

    public String unlimitedEndpoint() {

        return "This API has no rate limit.";

    }

}

10.保障接口安全

配置黑白名单，用Bloom过滤器实现黑白名单的配置

具体代码不贴出来了，大家可以去看看布隆过滤器的具体使用

11.接口控制锁粒度

在高并发场景下，为了防止超卖等情况，我们会对共享资源进行加锁的操作来保证线程安全的问题，但是如果加锁的粒度过大，是会影响

到接口性能的。那什么是加锁粒度呢？举一个例子，你带了一封情书回家，但是不想被爸妈发现，然后你偷偷回到房间里放到一个可以锁

住的抽屉里面，而不用把房间的门锁给锁上。无论是使用synchronized加锁还是redis分布式锁，只需要在共享临界资源加锁即可，不涉

及共享资源的，就不必要加锁。

锁粒度过大：

把方法A和方法B全部进行加锁，但是实际上我只是想要对A加锁，这就是锁粒度过大

void test(){

    synchronized (this) {

       B();

       A();

    }

}

缩小锁粒度

void test(){

       B();

    synchronized (this) {

       A();

    }

}

12.避免长事务问题

长事务期间可能伴随cpu、内存升高、严重时会导致服务端整体响应缓慢，导致在线应用无法使用

产生长事务的原因除了sql本身可能存在问题外，和应用层的事务控制逻辑也有很大的关系。

如何尽可能的避免长事务问题呢？

1.RPC远程调用不要放到事务里面

2.一些查询相关的操作如果可用，尽量放到事务外面

3.并发场景下，尽量避免使用@Transactional注解来操作事务，使用TransactionTemplate的编排式事务来灵活控制事务的范围

在原先使用@Transactional来管理事务的时候是这样的

@Transactional

public int createUser(User user){

    //保存用户信息

    userDao.save(user);

    passCertDao.updateFlag(user.getPassId());

    // 该方法为远程RPC接口

    sendEmailRpc(user.getEmail());

    return user.getUserId();

}

使用TransactionTemplat进行编排式事务

@Resource

private TransactionTemplate transactionTemplate;



public int createUser(User user){

    transactionTemplate.execute(transactionStatus -> {

      try {

         userDao.save(user);

         passCertDao.updateFlag(user.getPassId());

      } catch (Exception e) {

         // 异常手动设置回滚

         transactionStatus.setRollbackOnly();

      }

      return true;

    });

    // 该方法为远程RPC接口

    sendEmailRpc(user.getEmail());

    return user.getUserId();

}

作者：radient
来源：juejin.cn/post/7343548913034133523

收起阅读 »

如何给application.yml文件的敏感信息加密？

Java

Hello，大家好，我是云帆。在我们传统的基于SpringBoot开发的项目中，在配置文件里，或多或少的都会有一些敏感信息，这样就会丢失一定的安全性，所以我们就需要，对敏感信息进行加密。我们可以使用jasypt工具进行加密。好了废话不多少，直接进入正题： 1...

继续阅读 »

Hello，大家好，我是云帆。在我们传统的基于SpringBoot开发的项目中，在配置文件里，或多或少的都会有一些敏感信息，这样就会丢失一定的安全性，所以我们就需要，对敏感信息进行加密。我们可以使用jasypt工具进行加密。

好了废话不多少，直接进入正题：

1. 导入依赖

<dependency>  

    <groupId>com.github.ulisesbocchio</groupId>  

    <artifactId>jasypt-spring-boot-starter</artifactId>  

    <version>3.0.5</version>  

</dependency>

我的Demo里使用的是SpringBoot3.0之后的版本，所以大家如果像我一样都是基于SpringBoot3.0之后的，jasypt一定要使用3.0.5以后的版本。

2. 使用jasypt

我们在配置文件里写几行配置

jasypt:  

  encryptor:  

    password: sdjsdbshdbfuasd  

    property:  

      prefix: ENC(

      suffix: )

password是加密密码，必须配置这一项，值可以随便输入。
prefix和suffix是默认配置，也可以自定义，默认值就是ENC(和)，这个是自动解密使用的。

2.1. 加/解密

jasypt 提供了一个工具类接口，StringEncryptor，这个接口提供了加解密方法。下面是他的源码。

public interface StringEncryptor {  

  

    /**  

    * 加密输入信息  

    *  

    * @param 要加密的信息  

    * @return 加密结果  

    */  

    public String encrypt(String message);  





    /**  

    * 解密加密信息  

    *  

    * @param 加密信息（encryptedMessage） 要解密的加密信息  

    * @return 解密结果  

    */  

    public String decrypt(String encryptedMessage);  

  

}

我们在 test 测试类中，将要进行加密的文本使用encrypt方法进行加密

@SpringBootTest  

@Slf4j  

class JasryptApplicationTests {  

  

    @Autowired  

    private StringEncryptor stringEncryptor;  



    @Test  

    void contextLoads() {  

        String username = stringEncryptor.encrypt("root");  

        String password = stringEncryptor.encrypt("root");  

        log.info("username encrypt is {}", username);  

        log.info("password encrypt is {}", password);  

        log.info("username decrypt is {}", stringEncryptor.decrypt(username));  

        log.info("password decrypt is {}", stringEncryptor.decrypt(password));  

    }  

  

}

上边代码，加密的内容是，MySQL的用户名和密码，同时对它们进行加密和解密，你当然可以对任意配置信息进行加解密操作。看看输出内容：

2023-07-23T18:59:50.621+08:00  INFO 9489 --- [           main] c.e.jasrypt.JasryptApplicationTests      : username encrypt is 61zSoixtNayUruXt5x84kEKO9jGnZObTGCa1+k5Yg9F7qSUiZvp5fG31AMuVqrot

2023-07-23T18:59:50.621+08:00  INFO 9489 --- [           main] c.e.jasrypt.JasryptApplicationTests      : password encrypt is a6snCZCkbQFKkQqxN2bS18ags04yZxH+THwIL5RjGocEjG9sLkJvvasPFFVxEBWv

2023-07-23T18:59:50.623+08:00  INFO 9489 --- [           main] c.e.jasrypt.JasryptApplicationTests      : username decrypt is root

2023-07-23T18:59:50.630+08:00  INFO 9489 --- [           main] c.e.jasrypt.JasryptApplicationTests      : password decrypt is root

加密默认使用的是PBEWITHHMACSHA512ANDAES_256加密
我们将密文，替换到数据源，配置：

spring:  

datasource:  

driver-class-name: com.mysql.cj.jdbc.Driver  

url: jdbc:mysql://localhost:3306/honey?useUnicode=true&zeroDateTimeBehavior=convertToNull&autoReconnect=true&characterEncoding=utf-8  

username: ENC(61zSoixtNayUruXt5x84kEKO9jGnZObTGCa1+k5Yg9F7qSUiZvp5fG31AMuVqrot)  

password: ENC(a6snCZCkbQFKkQqxN2bS18ags04yZxH+THwIL5RjGocEjG9sLkJvvasPFFVxEBWv)

⚠️注意别忘了加上前缀和后缀，如上边代码。

这个时候就已经完成了，但是官方不建议我们将加密密码放到配置文件中，我们应作为系统属性、命令行参数或环境变量传递，只要其名称是 jasypt.encryptor.password，就能正常工作。

我们可以将项目打为jar包然后使用 java -jar命令

java -jar jasrypt-0.0.1-SNAPSHOT.jar --jasypt.encryptor.password=加密密码

⚠️加密密码必须与之前给属性加密时用的加密密码一致。

3. 结尾

好了，分享到这里就结束了，希望小伙伴们多多点赞，如果有建议，欢迎留言。

此致

作者：寒江雪369
来源：juejin.cn/post/7258850748149203000

收起阅读 »

我使用 GPT-4o 帮我挑西瓜

ChatGPT

hi，这里是小榆。在 5 月 15 日，OpenAI 旗下的大模型 GPT-4o 已经发布，那时网络上已经传开，但很多小伙伴始终没有看到 GPT-4o 的体验选项。在周五的时候，我组建的 ChatGPT 交流群的伙伴已经发现了 GPT-4o 这个选项了，是...

继续阅读 »

hi，这里是小榆。在 5 月 15 日，OpenAI 旗下的大模型 GPT-4o 已经发布，那时网络上已经传开，但很多小伙伴始终没有看到 GPT-4o 的体验选项。

在周五的时候，我组建的 ChatGPT 交流群的伙伴已经发现了 GPT-4o 这个选项了，是在没有充值升级 Plus 版的情况下，意味着这个模型已经更新给大众免费使用了。

我看到后，立马放下手中正在编写的代码，开启 GPT 登录后果然有一个 GPT-4o 的选项，然后发现它的功能比 3.5 模型更加全面了，它不仅能够全面覆盖听觉、视觉和语音。

我体验了一把语音对话，非常的丝滑没感觉到延迟，仿佛真的和“女朋友”在聊天。意味着它能够感知我们的呼吸节奏，并用更加丰富的语气实时回应，还会在适当的时候打断对话。

那么，就让我们了解 GPT-4o 这个大模型吧，首先 GPT-4 是比 3.5 版本更强的版本，即为 4.0+，后面还有一个‘o’ ，它的全称是‘Omni’，即‘全能’的意思。

它能够接受文本、音频和图像的任意组合输入，并生成回答。响应速度快至 232 毫秒，平均 320 毫秒，与人类对话的速度可以说是很接近平均了。

并且，随着这次版本的发布，GPTo 与 ChatGPT Plus 会员版的所有功能，包括视觉、联网、记忆、执行代码、GPT Store 等，都会免费开放给大家。新语音模式将在几周内优先向 Plus 用户开放。

在直播现场，OpenAI CTO Murati 谦虚道：“这是将 GPT-4 级别的模型开放给大家。”

同时将这一版本的模型提供 API 服务，价格随之减少一半，速度比之提高一倍，单位时间内调用次数是原来的 5 倍了。

OpenAI 的总裁 Brockman 也给大家在线演示，将两个 ChatGPT 相互对话，对话内容比较丰富了，不知不觉还唱起歌来了，整的还挺有意思。

发现还有伙伴和我一样体验到了不错的应用场景，当我使用手机版的 GPT-4o ，我可以实时拍照询问它，给我一些建议，如何挑西瓜榴莲等，询问给出差异分析，借助 AI 的力量进行挑瓜。

你甚至可以拍摄一批西瓜的照片，上传给 GPT-4o。

你：“这瓜保熟吗？”

AI：“（警觉）...你故意找茬是不是。”

AI：“我一AI，还能给你挑生瓜蛋子不成？！”

我们可以看到上图中的西瓜是根据自己拍摄的西瓜图并且标记了序号，询问 GPT 哪个西瓜很甜，GPT 一通分析，虽然目前只能根据形状和成色来识别西瓜，推荐挑选的 6 号西瓜果然很不错，甚至皮也很薄。

聪明的你，脑洞大开已经熟练使用 AI 了，你或许会有很多问题问他。

你：“这盒牛奶含有什么成分？”

AI：“......”

你（掏出手机，打开摄像头扫描）：“这盒牛奶有科技成分吗？卫生是否达标？”

AI：“......”

你（掏出手机，打开摄像头扫码）：“请问这个妹妹面相如何？是否旺夫？”

AI：“......”

显然，上面有一部分是我的遐想，但我觉得已经不远了。

如果 AI 没有被一方人污染，升级完全体的情况下，它真的能够为我们参谋很多，洞悉很多潜在的信息，毕竟你能骗我，但是 AI 不会骗我。

好了，大家可以多去体验新产品吧，的确会很有趣。但是发现很多小伙伴不仅电脑版本的 GPT 无法体验，更别说手机版本的 GPT 了。

目前来说对一些普通用户体验的确很困难，被迫使用某些企业研发的 AI 产品或套壳产品，还被迫收费。但也不是没有办法，别说我还挺想撰写一篇从 0 到 1 给大家完全科普使用。

okay，分享（暗示）到这里，大家如果有感兴趣，可以后台回复 GPT 加入群聊，将会有更多咨询和体验内容分享。

作者：程序员小榆
来源：juejin.cn/post/7370327567763816498

收起阅读 »

坚持与确定性：毒药还是良药？

职场话题

前段时间跟几个大龄程序员一起吃饭，聊了大家的现状，后来写了篇博客总结了一下《从大龄程序员现状聊聊出路》，本想着给朋友们提供些观点和思路，结果被有些网友批评了。 1. 我的认知达不到赚快钱有的网友认为我在瞎扯，有的觉得我在灌鸡汤，还有的认为我在指错路。文中虽...

继续阅读 »

前段时间跟几个大龄程序员一起吃饭，聊了大家的现状，后来写了篇博客总结了一下《从大龄程序员现状聊聊出路》，本想着给朋友们提供些观点和思路，结果被有些网友批评了。

1. 我的认知达不到赚快钱

有的网友认为我在瞎扯，有的觉得我在灌鸡汤，还有的认为我在指错路。

文中虽然总结了一些自认为有价值的观点，本想着让看到的朋友能够少走弯路，尽早建立正确的思维方式。但是依旧没法满足部分网友想轻易赚块钱的思路。我实在是感到惭愧。

对于想赚快钱的网友，你们也可以去参考下刑法里的路子，或者去网上买点教你如何赚钱的课嘛，何必在这浪费口舌呢。

我在那篇文章里提到了坚持、积累、人脉、资源、推广等关键因素，每一个都不是速成的。每一项都需要长期努力，不是一蹴而就的。反正在我的认知里，每一个成功的背后都是：找到了正确的道路后，不停的微调，默默的坚持。

2. 少有的坚持

各位也可以试想下，想想这些年看过的赚钱课程，或者什么创业导师商学社等等，他们除了制造些焦虑，讲一些假大空不好落地的概念之外，其余的好像都是正确的废话吧？

远的不说，就以程序员做副业为例，有各种建议，比如做自媒体、接项目、搞某鱼某宝或卖课。这些导师对这些方法都提供了具体的行动方案，请问你是否开始行动了？是否坚持了？是否取得了成效？

这些路子是不是都是对的呢？无疑都是对的，但是每条路子都不好走，都需要自己去坚持去深钻。你都不愿意去深钻，怎么可能赚的了那份钱呢？

真的是应了那句话：我知道了那么多道理，依然过不好这一生。知道、做了、做到、做得好，是4个完全不同的概念。

许多人回忆自己几十年好像什么都没做，好像又做了很多事。为什么出现这种幻觉？因为没有坚持、没有产品思维，没有拿得出手的作品嘛。好的作品不用多，一个就够！

希望所有的朋友，都能具备产品思维。就是：认真、坚持的打磨好一件事情，把这件事情做到产生价值甚至巨大的价值，做到对他人有利，做到能够盈利，然后再去打磨下一个产品。

坚持绝对是创业或者副业路上的一副良药。道阻且长，行则将至！与君共勉！

3. 确定性是一副毒药

后来我又思考了下，为什么有些程序员朋友对于正确的事情却无法坚持执行下去呢？这可能不是他们的问题，可能是我们程序员这个群体的问题。

为什么？因为就算坚持下去，也不一定能拿到想要的结果，这里面不确定的成分太高了，他们不愿意面对这份不确定性。

程序员这个群体是搞技术的，技术本身就是确定性的，非此即彼嘛。

大部分程序员学技术这条路子也是冲着确定性去的，比如我就算一个，当年学计算机就是为了确定性的找到一份稳定的工作，我早年特别害怕面对不确定性。

程序员学会了某个前端技术或者后端技术，对应的就能确定的拿到了一份什么等级的薪资。埋头苦干，确定的就会有一个好的结果。

但是，那些创业和副业都是不确定性的。创业和副业不是说通过学习或者努力就能达到一个确定性的位置。所以说呀，与其说有些网友在喷我，倒不如说是他们不敢面对不确定性。

但是，朋友们，时代在变化，我们每个人都要敢于面对不确定性。

早年我们处在IT红利期，只要努力，到处是机会。确定的程序，确定的路径，确定的繁荣，让我们误以为这个世界可以一直确定下去。这种确定性让我们慢慢上瘾，最终失去了面对不确定性的能力和勇气。

想想当年学计算机那么多人是为了图个安稳，结果过了十几年，还是没能逃脱不确定的因素，如果早日接受不确定性，可能眼界会更开阔一些。

没想到十年前的那颗子弹最终还是中了自己的眉心。

以后，随着AI的发展，我觉得未来一定是一个超级个体的时代，我们会面临更多的不确定性。以后社会发展也会伴随着更多的不确定性，只有我们要调整好心态，接受它，才能在以后的道路上越走越宽，越走越顺。

趁现在就改变，千万别让确定性这副慢性毒药继续侵蚀我们的思想。

原文链接： mp.weixin.qq.com/s/9QZHF7ria…

作者：程序员半支烟
来源：juejin.cn/post/7379414160642654260

收起阅读 »

快速背景

新提案：追求类似 try-catch

新的争端：官方你行你上

Go 官方回应

总结

1、引言

2、实现过程

预想一下如何使用这个字典 hook？

最近也在写 vue3 的项目，用 vue3 也实现一个吧。

到此结束！如果有错误，欢迎大佬指正~

运维打工人，周末兼职送外卖的一天

前言

官网自定义tabbar

bug产生原因

解决tabbar闪烁问题

写在最后

故事背景

自我介绍

养生日常

7点起床，7.30做饭

9点到公司，开始工作吃早饭

5点30下班

周末

周六外出

周日创作

总结

什么是学生思维

建立全新的职场思维体系

1：工作只是利益的结合，天下没有不散的宴席

2：努力适应变化，生活不是考试，不需要排名

3：不要妄图规划未来，先把当下的事情做好

总结

AdGuard 拦截器

Global Speed

Imagus

Picture-in-Picture Extension

购物党自动比价工具

SuperCopy 超级复制

如何安装

什么是 Skyline

将开发者工具切换成 Sykline 模式

使用 skylint 工具迁移

手动迁移

在真机上调试 skyline 渲染模式

常见问题

position: fixed 不支持

不支持 Canvas 旧版接口

在真机中图片的 referer 丢失

官方 Demo

参考

djngo开发：小程序实现无感登录+权限分配

由来

1. 开发思路

2.简单实现

3.更进一步：通过手机号来区别普通用户和工作人员

3.1 前端获取手机号的动态令牌

3.2 后端带着动态令牌去微信服务器获取手机号

1、问题背景：

2、排查步骤：

1）借助SGM打印栈信息﻿﻿

2）分析栈信息

2.1）分析线程状态

2.2）分析线程夯住的方法

2.3）从业务的角度分析持有写锁的逻辑

2.4）深入挖掘原因

2.5）验证

3.复盘

序言

Nuget 包

素材准备

代码展示

结束语

概述

定位原因

压缩资源

网络请求

隐私协议

背景

微信授权流程

uniapp代码实现

1）借助SGM打印栈信息

好我们知道有这个懂就行,后面我们进行创建我们的自定义菜单栏组件 `tabbar.vue`

我们自定义的效果出来了但是下面是什么鬼.....
可以看到我们下面也有一个菜单栏是 tabbar 配置产生出来的,我们前面不是说了隐藏吗?
修改函数新增隐藏tabbar代码
`// 隐藏原生TabBar uni.hideTabBar();`

本期结束咱们下次再见👋~
🌊 关注我不迷路，如果本篇文章对你有所帮助，或者你有什么疑问，欢迎在评论区留言，我一般看到都会回复的。大家点赞支持一下哟~ 💗

作者：杨不易呀
来源：juejin.cn/post/7330295657167290403