La promesse n'est pas la solution finale et elle n'est pas nécessairement plus élégante que les rappels asynchrones/attendre

Il y a trois points. Écrivez le code ci-dessus directement dans le then de db_conn, puis renvoyez-le
Utilisez catch dans la couche la plus externe pour capturer les exceptions.
Supprimez le console.log, ça a l'air bizarre,

db_conn()
.then(db=>{
        return {
               db:db,
               test:'test',
               data:{}
         }
})
.then(findOneData)
.then(r=>{
   console.log(r);
});

Enfin, changez la façon dont votre findOneDatareçoit les paramètres. Est-ce mieux ?

db_conn()
    .then(db => findOneData(db, "test", {}))
    .then(data => console.log(data));

Cela n’a-t-il pas l’air plus agréable à regarder ?

(async function() {
    const db = await db_conn();
    const data = await findOneData(db, "test", {});
    console.log(data);
})();

Est-ce plus agréable à regarder ?

La solution Promise résout le problème des rappels asynchrones sans ajouter d'éléments de langage, il doit donc y avoir certaines limitations.

En plus des rappels d'origine, Promise ajoutera au moins une couche de rappels, donc lorsque la chaîne de rappel d'origine est très courte, comme dans le cas du sujet, il n'y a qu'une seule couche, il semble qu'il n'y ait aucun avantage à utiliser Promise , ce qui est normal.

Si vous rencontrez des situations plus complexes et plus de niveaux d'imbrication, vous pouvez voir l'intérêt d'utiliser Promise.

Tout le monde à l'étage a fourni de bonnes méthodes d'écriture, donc je n'en dirai pas plus.